41–50 of 98 posts
One thing about Cargo's lack of 'vendoring' on the checkmark list; there is https://github.com/alexcrichton/cargo-vendor , and soon there will be https://github.com/rust-lang/cargo/pull/2857
On the CF buildpacks team in NYC, lack of vendoring prevented us from completing a buildpack that would work in disconnected Cloud Foundry installations. We were sad.
Call me old fashioned, but I find it annoying that every new language nowadays seems to want to pull in its own package manager, redundantly parallel to the perfectly good one my operating system provides. I am already perfectly fine with installing my software through apt-get. Why oh why do I need pip, and gem, and npm, and CocoaPods, and cargo, and NuGet, and on and on and on... Using a new language is no longer a…
Because apt-get doesn’t exist on the system I use, and most system packagers can’t/won’t keep up with the rate of change of development, anyway. CPAN, RubyGems, etc. all exist because system packaging systems are (a) specific to a particular distribution, (b) generally many versions behind the development versions, (c) really hard to get into unless you are already a system packager for a particular distribution, and…
- It does mean that the common libraries are installed once - conflicts between common libraries are more transparent - System tools make sure that package stays up-to date
Fwiw pip isn't even able to enforce versions correctly (packages are installed as the file is read, and can conflict with previously expressed constraints). Or report installed versions correctly (it's possible that packages are half-installed or installed but not reported as such by pip commands).
Since I had starting looking for an alternative to NPM I have discovered a couple of things: * All current package managers are either language or OS specific. What if you have an application with code written in multiple languages? * NPM didn't have any kind of integrity checks for its packages, and I assume most package managers don't either. If you download a corrupt package, for example, you won't have any idea a…
It would be nice if the Go crowd and the Rust crowd, both of which are developing new package managers, had at least a common spec on how to describe dependencies.
It's already very hard to find a programmer that writes a lot in more than one language and cares about packaging/deploying software.
This should probably use Stack for Haskell as well, which was designed to solve various common issues that arise when using cabal as a package manager.
Which one allows to import multiple versions of a lib/module/package with different versions? (Not primarily but also an issue of the package manager.)
Npm allows that.
Cargo supports vendoring and enforces semver. Not sure why that document disagrees.
The difference is in the central repository: Elm will compare your types to the previous versions and how the versions diff, and refuse to let you upload a package that makes a backwards incompatible change without bumping the version. At least, that's my understanding of what they meant.
Earlier quoted context omitted.
Prepare for the hate-train from developers. But I agree with you though. It's frustrating because each PM wants to install it's own version, which ends up conflicting with another PM's version, and who knows where they end up, or in what state. Apt-get rarely fails for me, but pip, gem, npm fail all the time. And who knows what version of the package they just installed, or where they got it from. I wish devs would j…
Actually no, it's not a terrible process, it's a misunderstood process[#]. Modern tools (debhelper 7+) allow for simple process, though one needs to understand how the binary packages thing works. This is a decent overview on technical details: http://vincent.bernat.im/en/blog/2016-pragmatic-debian-packa... [#] I assume you meant the friction with the tools, not the fact that package builder needs to chase down all t…
I write apt-packages all the time. I get the process. And yes, it's still terrible. And when you consider that devs need to know how to build for apt-get, yum, etc, it's understandable, IMO, why they don't want to bother.
Earlier quoted context omitted.
It would be nice if the Go crowd and the Rust crowd, both of which are developing new package managers, had at least a common spec on how to describe dependencies.
This requires a programmer who writes a lot in both languages, who has enough energy left to help with two package managers, and who happened to be in the right places in the right moments to actually join the projects. It's already very hard to find a programmer that writes a lot in more than one language and cares about packaging/deploying software.
(And then there's catkin, the build system for the Robot Operating System. That's the build job from hell. ROS is a message-passing environment to which a huge number of existing packages have been adapted. Multiple languages, different underlying libraries, and no central control of versions across packages. It sort of works. Although there are bad days when it breaks the Ubuntu updater.)
https://www.dartlang.org/tools/pub
It hews pretty closely to Bundler's model (versions, version ranges, lockfiles, shared dependencies), though. So I don't know if it gives you much insight beyond "Yes, another language team things Bundler is on the right track."
Personally, I have a hypothesis that states that all programming languages either have a package manager that works like Bundler or will end up getting one.