Cargo, Rust's Package Manager • Hacker News Board

Re: Cargo, Rust's Package Manager

#121

Post by nirvdrum » Wed, Jun 25, 2014, 4:41 AM UTC

burntsushi wrote: post #116

nirvdrum wrote: post #66

Earlier quoted context omitted.

That's not really carte blanche to build everything on unstable technology. The point is things are supposed to be converging on stabilization. And a lot of what's unstable now is under the direct control of Rust. What TOML does or doesn't do is now a matter that needs to be worked out with Tom. It's not confidence-inspiring in the least. If the plan is to jettison TOML, then it's simply just an odd choice to use for…

> What TOML does or doesn't do is now a matter that needs to be worked out with Tom. For what it's worth, I've just been brought on as a maintainer for TOML proper. Tom is still the guy though. Putting aside my involvement with Rust (<3), I also maintain the TOML library for Go, and I want to see an expedient path to 1.0 with minimal breakage. (There are lots of folks in the Go community already using TOML for things…

I saw that, based upon Steve's linked issue elsewhere in this thread. I think that's great and would go a long way in addressing some concerns here. Moving it to an organization is reassuring as well. Thanks for the update!

Re: Cargo, Rust's Package Manager

#122

Post by mercurial » Wed, Jun 25, 2014, 4:53 AM UTC

progx wrote: post #18

Svip wrote: post #4

Earlier quoted context omitted.

I may not be a majority here, but I see JSON as a data transportation format, while I see TOML or YAML as configuration formats. You cannot write comments in JSON, for instance.

Example from the website in json { 'package': { 'name': 'hello-world', 'version': '0.1.0', 'authors': [ 'wycats@example.com' ] }, 'bin': { 'name': 'hello-world', 'comment': 'the name of the executable to generate' } } So where is the problem ? And you have the advantage, that other tools can use the complete file including the comment. In TOML you need an extra parser to grab the comment.

It's sad to see that the guidelines about downvoting are clearly not respected.

Re: Cargo, Rust's Package Manager

#123

Post by mercurial » Wed, Jun 25, 2014, 12:14 PM UTC

bronson wrote: post #115

steveklabnik wrote: post #108

Earlier quoted context omitted.

Quite fair. Depends on what kind of tradeoff you're looking for: this personally makes me search for a new format. It's reasonable to make a different choice.

I don't even think that's fair. What happens when everyone implements their own pet subset of a standard?

It's not an hypothetical future, you can often disable dangerous features in XML parsers. It seems sensible to me to do the same with YAML parsers.

Re: Cargo, Rust's Package Manager

#124

Post by Argorak » Wed, Jun 25, 2014, 12:50 PM UTC

awj wrote: post #81

Argorak wrote: post #53

Earlier quoted context omitted.

Don't equate Rails with Ruby (some projects follow semver very closely). Rails follows a shifted semver version, as documented here: https://github.com/rails/rails/blob/master/guides/source/mai... Bumps from 4.x to 4.y might contain smaller breaking changes. For a large project as Rails, I find that reasonable, otherwise, we'd be at Rails 20 by now, which also doesn't quite give a good sense of how the project evolve…

MRI didn't follow semver up until recently, and even now it has some caveats about it. Ruby as an ecosystem doesn't really care for semver. Some projects follow it anyways, which I can respect, but they aren't the norm.

MRI picked its version scheme in the 90s, long before "semver" was a thing. That kind of version scheme wasn't unusual in that time. Problems due to legacy don't make a good argument.

The Ruby system cares for semver in general and it is propagated there a lot, but I agree: it certainly isn't uniform.

Re: Cargo, Rust's Package Manager

#125

Post by dmacvicar » Wed, Jun 25, 2014, 6:15 PM UTC

Sanddancer wrote: post #39

Will this play nicely with the package management tools OSes already have, or is this going to end up being yet another source for files/packages to accumulate that are outside the view of well-documented and designed administrative tools?

Each language having its own tools is fine and I doubt OSes are against that. Those tools just need to support a very specific set of features or scenarios to make packaging easy:

Understand that enterprise OSes are not built on developer Macbooks. Enterprise distros have reproducible builds on automated systems with chroots that contain only what the package needs, no network access and sometimes the build happens inside a virtual machine. Its is almost ridiculous how after maven forgot the topic of being "offline" almost every tool released afterward has done the same mistake.

Understand that Linux distributions sell support and that means being able to rebuild a patched version of a failed package. So whatever dependencies are pinned in Cargo.toml or Gemfile is irrelevant. The OS maker will override them as a result of testing, patching or simply to share one dependency across multiple packages. Distros can't afford having one package per git revision used on a popular distro and then afford to fix the same security issue in all of them.

So having "cargo build" be able to override dependencies and instead look on the installed libraries with a command line switch or env variable helps the packager not having to rewrite the Cargo.toml in the package recipe.

Maven was probably the first tool that made packaging almost impossible and completely ignored the use-case of patching a component of the chain and be able to rebuild it completely.

Semantic versioning is great news, because it allows you to replace the dependencies for a common semantic version (not exactly the same).

For integrating with the C libraries not much needs to be done. If you support pkg-config then you cover 85% of the cases.

Re: Cargo, Rust's Package Manager

#126

Post by sanderjd » Wed, Jun 25, 2014, 8:40 PM UTC

Sanddancer wrote: post #119

sanderjd wrote: post #44

Earlier quoted context omitted.

I think it would be just as easy to package rust programs using OS native package management as anything else, and I'm sure packages will be made for popular things for common package managers. But OS native package managers are a royal pain to use when actively developing on a project that has some dependencies, and bespoke Makefiles are a very imperfect solution. Flipping your question around a bit: will package ma…

Have you taken a look any at the FreeBSD ports system? It uses makefiles to manage pretty much any software install you can think of. Additionally, there's a pretty good infrastructure there for managing custom build trees, etc. Additionally, they also have things like BSDpan that let you use arbitrary Perl modules with the package management system.

I've used ports, but I've never developed a project using it, so maybe I should try that out. But "uses makefiles" does not make me particularly optimistic for its pleasantness. I really prefer (and think it's been proven possible to build) declarative, rather than imperative, systems for managing dependencies.

Re: Cargo, Rust's Package Manager

#127

Post by Sanddancer » Thu, Jun 26, 2014, 6:34 AM UTC

shadowmint wrote: post #118

Sanddancer wrote: post #117

Earlier quoted context omitted.

Which is why we have testing and staging environments to make these changes on first. Conversely, when everything is pulling in their own version of a library, you run into situations like the zlib buffer overflow, where you had huge numbers of programs that needed to be rebuilt because no one used system-packaged libraries. Obsolete and vulnerable software is a liability, and not having tools which can readily tell…

You can't have it all. Either you rely on system librarys OR every binary / library pulls in its own copy of its dependencies (npm model). The latter lets you have multiple versions of the same library for different dependencies, without confusing your system package manager. The former might mean 'less build time', but it's pretty much whats wrong with the C/C++ ecosystem; you can't track the system libraries from t…

I'd say look at the BSD ports system for an example of a system done well, and is extensible to such issues. If your app depends on projects with irresponsible developers that make unannounced API/ABI changes and the like, the general format of the ports system, and tools for maintaining private repositories like portshaker and poudriere, make it easy to create ports that let you have the best of both worlds. To add to this, one can use metapackages and the like which don't have any files in and of themselves, but will point to the latest version. So, for example, you create a port named libbar, which is always going to get you the latest and greatest, but you also have libbar-1, libbar-12, etc, that you can use when you need an explicit dependency. Additionally, there are ports of the system library -- heimdal, openssl, etc, so you can have a stable base system, but still have more recent versions around for your application. Most of the issues people have with packaging these projects seems to be much more based around inexperience with good packaging tools and practices, rather than the idea of system packaging in and of itself.