4 ms·

Op here. I'm not sure what the right solution is. Each of the major package management solutions have provided ways to talk to independent repositories. I thi

Op here. I'm not sure what the right solution is. Each of the major package management solutions have provided ways to talk to independent repositories. I think that, in some ways, it makes a sense for a language to maintain repositories for each of the major OSes. This isn't without problems, of course, because then instead of writing software, you're spending time packaging and testing that, when you could just make a ruby gem and be done with it. Which is what happens now. Honestly, even a way to conclusively enumerate the installed packages, versions, and sources of each package would be an improvement. That way, I could at least be reasonably assured of recreating the environment.

dcosson 13y ago
> Honestly, even a way to conclusively enumerate the installed packages, versions, and sources of each package would be an improvement I feel like there are usually ways to do it, you just have to really go out of your way and it's not normally the default or even recommended way of doing things (which is a problem, to be sure). Using the puppet example, the forge is definitely terrible, the published "versions" are often not tagged or tagged differently on github, modules rarely have been updated with bug fixes from the past 2 years, etc. But most of the sources are on github so you can fork them, tag with symantic versions, and use something like librarian or r10k to enumerate those versions and deploy your environment. Of course then you're kind of using your own custom system which can have its own problems, but you can be reasonably sure that for a particular project you could re-deploy exactly the same modules as long as you have that Puppetfile.
PeterisP 13y ago
I can't agree that it makes sense for a language to maintain repositories "for each of the major OSes". In general, those modules are OS-independent, that's the whole point - no matter if I'm on Ubuntu or Windows or some-obscure-definitely-not-major OS, I should have the same repository with the same download; and I can distribute a package that will be available and work on MacOS without needing a Mac. This also means that OS-specific package managers aren't usable - the same package manager should work the same way regardless of which OS is used. If I have a dropbox folder with my project and it's package requirements, then for most modern languages the exact same folder simply works on my Mac, Win and Linux computers. "conclusively enumerate the installed packages, versions, and sources of each package" - most package managers do so. Many allow a project to define not only the package needed, but also the package version; and they are able to automagically download and use package version 1.2.3 for project A, while keeping the 2.0.0.alpha version of the same package available for project B.
shadowmint 13y ago
I think that, in some ways, it makes a sense for a language to maintain repositories for each of the major OSes. Specifically with regard to rust, what exactly does that mean? Are you suggesting that if someone writes a rust library they should publish an .rpm, a .deb, an insert-here for osx, and an installable .exe (or nuget package) from a centralized repository? Or push them to the upstream providers for each distribution? Or something else entirely?
- deleted 13y ago
  [deleted]

dcosson 13y ago

> Honestly, even a way to conclusively enumerate the installed packages, versions, and sources of each package would be an improvement I feel like there are usually ways to do it, you just have to really go out of your way and it's not normally the default or even recommended way of doing things (which is a problem, to be sure). Using the puppet example, the forge is definitely terrible, the published "versions" are often not tagged or tagged differently on github, modules rarely have been updated with bug fixes from the past 2 years, etc. But most of the sources are on github so you can fork them, tag with symantic versions, and use something like librarian or r10k to enumerate those versions and deploy your environment. Of course then you're kind of using your own custom system which can have its own problems, but you can be reasonably sure that for a particular project you could re-deploy exactly the same modules as long as you have that Puppetfile.

PeterisP 13y ago

I can't agree that it makes sense for a language to maintain repositories "for each of the major OSes". In general, those modules are OS-independent, that's the whole point - no matter if I'm on Ubuntu or Windows or some-obscure-definitely-not-major OS, I should have the same repository with the same download; and I can distribute a package that will be available and work on MacOS without needing a Mac. This also means that OS-specific package managers aren't usable - the same package manager should work the same way regardless of which OS is used. If I have a dropbox folder with my project and it's package requirements, then for most modern languages the exact same folder simply works on my Mac, Win and Linux computers. "conclusively enumerate the installed packages, versions, and sources of each package" - most package managers do so. Many allow a project to define not only the package needed, but also the package version; and they are able to automagically download and use package version 1.2.3 for project A, while keeping the 2.0.0.alpha version of the same package available for project B.

shadowmint 13y ago

I think that, in some ways, it makes a sense for a language to maintain repositories for each of the major OSes. Specifically with regard to rust, what exactly does that mean? Are you suggesting that if someone writes a rust library they should publish an .rpm, a .deb, an insert-here for osx, and an installable .exe (or nuget package) from a centralized repository? Or push them to the upstream providers for each distribution? Or something else entirely?

deleted 13y ago
[deleted]