Cargo supports vendoring and enforces semver. Not sure why that document disagrees.
Can you point to where Cargo supports vendoring? Curious to read some docs.
Comparison of Programming Language Package Managers
61–70 of 98 posts
Re: Comparison of Programming Language Package Managers
#62Perl's CPAN has tooling for diffing versions through the use of MetaCPAN (a top-notch site which every language should try to emulate). For example, here is a diff of the URI distribution: https://metacpan.org/diff/file?target=ETHER%2FURI-1.71%2F&so... This information is also available through an API for integration into command line tools.
IIRC, and I could be wrong, CPAN was the first to go down the route that many modern toolchains now provide. We've looked at it. In fact, the original creator of Glide (Go package manager) wrote about Perl and CPAN when talking about Go at http://technosophos.com/2015/09/02/dont-let-go-be-condemned-... .
Yeah, I think it was. The only thing older was probably CTAN, but it didn't have the same structure.
Other things from the Perl ecosystem that should be copied are:
- CPAN Testers which automatically tests every package on multiple systems from Windows to Solaris. This helps identify portability, backcompat, and regression issues.
- CPAN mirrors which ensure that there isn't a single point of failure. This might not be as important now with fast networks and high uptimes, but it also ensures that everyone can replicate all of the code at anytime. I believe R's CRAN does this.
Re: Comparison of Programming Language Package Managers
#63I don't get why "pip" is checked in "Has separate manifest and lock files". Actually it doesn't have that feature (which Bundler for Ruby has, for instance). This very feature comes with a third-party package called "pip-tools", or possible alternatives, but raw pip doesn't have this ability directly afaik. Fwiw pip isn't even able to enforce versions correctly (packages are installed as the file is read, and can con…
Pip has a constraints file now. Running
$ pip freeze -r requirements.txt > constraints.txt
$ pip install -r requirements.txt -c constraints.txtRe: Comparison of Programming Language Package Managers
#64Earlier quoted context omitted.
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.
Hm, even without the above stuff, `cargo fetch` should enable you to do offline builds just fine.
Can you point to a man page? We weren't able to find a reference doc on the cargo site.
Re: Comparison of Programming Language Package Managers
#65Call 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…
Yep. I always feel extremely uneasy when I encounter a codebase that asks me to install its language's package manager (npm I'm looking at you) as root. I just go 'nope' the only thing that touches my real system is portage. Even using npm or pip as a non-root user worries me because there is an entire extra level of validation missing and it signals to me that developers are not doing due diligence and working with distro maintainers. Yes I know it is more work, but it is an incredibly important step for quality control. The kids these days seem to think that containerization will solve everything, but these problems cannot be avoided.
Re: Comparison of Programming Language Package Managers
#66Earlier quoted context omitted.
> It is widely discouraged It is also widely encouraged. Some engineers: 1. Don't trust dependencies to always be there. 2. Write apps that need to work in disconnected environments -- ie with no internet connectivity. I work on the Cloud Foundry buildpacks team for Pivotal. Being able to stage and launch apps in a disconnected environment is A Big Deal for a lot of companies.
Absolutely. That’s sort of a fundamental reason why I wrote Cartage. I like some of what Capistrano does, but the general insistence on being able to `bundle install` on the target server is questionable, and the earlier practice for Rails apps of keeping the gems in Git resulted in other problems. Heroku mostly does this right with its 'slug' system, and I made Cartage specifically to be able to make deployable pack…
Cloud Foundry has staging and run steps, much as Heroku does, to the point that a lot of Heroku buildpacks will run without modification ... if you're in a fully connected environment at staging time. It's not an accident: Cloud Foundry was in part consciously inspired by Heroku in the early days, so adopting the buildpacks model was natural.
However, as I noted above, this model breaks for disconnected environments, in which neither the staging container nor the runtime container have internet connectivity.
Heroku's ruby buildpack code runs bundler, Cloud Foundry's buildpack is a soft fork of Heroku's, so either you vendor your dependencies before sending it to Cloud Foundry for staging, or you get a failed staging step when the code in the staging container can't dial out to a remote repo.
Re: Comparison of Programming Language Package Managers
#67Call 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…
Yep. I always feel extremely uneasy when I encounter a codebase that asks me to install its language's package manager (npm I'm looking at you) as root. I just go 'nope' the only thing that touches my real system is portage. Even using npm or pip as a non-root user worries me because there is an entire extra level of validation missing and it signals to me that developers are not doing due diligence and working with…
Most language module systems don't need root. Certainly none of the mainstream ones.
Containers don't "solve" everything, but some of the primitives used to build them can be used to severely restrict process and user privileges -- to the level that it's much more secure than a "standard" unix-y shared environment.
Re: Comparison of Programming Language Package Managers
#68I know Dart isn't super widely used, but it's package manager, pub, is probably a good reference for this. We put a ton of work into it, and Dart users regularly single it out as one of the compelling parts of the Dart platform. 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 b…
Based on my work in buildpacks, I agree with the sentiment but I'm not as hopeful as you are.
Re: Comparison of Programming Language Package Managers
#69Cargo supports vendoring and enforces semver. Not sure why that document disagrees.
> Not sure why that document disagrees
Probably because of this[0]:
> Note that Cargo does not yet support vendoring in a first-class fashion, but this is a hotly desired feature and coming soon!
[0] http://doc.crates.io/faq.html#how-can-cargo-work-offline
Re: Comparison of Programming Language Package Managers
#70I don't get why "pip" is checked in "Has separate manifest and lock files". Actually it doesn't have that feature (which Bundler for Ruby has, for instance). This very feature comes with a third-party package called "pip-tools", or possible alternatives, but raw pip doesn't have this ability directly afaik. Fwiw pip isn't even able to enforce versions correctly (packages are installed as the file is read, and can con…
Pip has a constraints file now. Running $ pip freeze -r requirements.txt > constraints.txt after you've installed all your packages gives you a constraints file that can be used to reinstall exactly the same versions: $ pip install -r requirements.txt -c constraints.txt
Didn't know that option thanks. Better than nothing, but unfortunately your environment is still subject to the remarks in my second paragraph. So pip-tools is still required if you want more guarantees.