Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cargo, Rust's Package Manager

crates.io

Post reply on HN
Print view View original

111–120 of 127 posts

Re: Cargo, Rust's Package Manager

#111

Post by TheHydroImpulse »

ripter wrote: post #97
bryanlarsen wrote: post #42

This is sweet: For example, if I have three packages: - uno depends on json 1.3.6 - dos depends on json 1.4.12 - tres depends on json 2.1.0 Cargo will use json 1.4.12 for uno and dos, and json 2.1.0 for tres. Hopefully rust builds a culture that respects semantic versioning better than the Ruby & Node cultures do. That has to start at the top. There were several Rails 2.3.X releases with minor ABI incompatibilities.…

Npm require modules to follow semver. https://www.npmjs.org/doc/package.json.html#version Now sure why you think the culture there doesn't respect semver.

Requiring a version number to be within the semver format is one thing; but abiding by the rules of semver is another thing entirely. You'll see plenty of Node packages break compatibility on minor or patch updates. It's not something I see as extremely important in that community.

Re: Cargo, Rust's Package Manager

#112

Post by awj »

steveklabnik wrote: post #80
adrusi wrote: post #78

Earlier quoted context omitted.

It would be impossible to do so perfectly for a turing complete language. You could get close by running the previous minor version's test suite against the new update, but that would essentially make the package repository into a continuous integration server, which is expensive to maintain. There's another, less perfect way of detecting API breakage, which is to use the rustdoc tool to export the projects documenta…

> which is to use the rustdoc tool to export the projects documentation as json. Side note: it already does this by defaut: http://doc.rust-lang.org/search-index.js I'm not sure if that's enough information to do this analysis, but the basics are there! I've opened an issue: https://github.com/rust-lang/cargo/issues/47

How hard would it be to get usable type signatures out of the compiler as well? It seems like diffing two sets of type signatures would capture everything but purely semantic api incompatibility. Also seems like "here's a machine-readable version of all the types in this package" is a useful thing for a compiler toolchain to produce.

Because, of course, Mozilla is paying you to sit around on your hands.

Re: Cargo, Rust's Package Manager

#113

Post by kolev »

sanderjd wrote: post #109
kolev wrote: post #104

Earlier quoted context omitted.

Stuff being either in Cask or Homebrew is just terrible. Homebrew also has a versions tap. Those two projects should combine efforts and remove ambiguity.

I 100% agree with you. It took me like an hour to figure out where I thought it made sense to put rust-nightly, and I'm still not really sure I did it right. But it works and is way better than the morning compilation cronjob I used to use.

I agree, it works, but we need to keep pressing those guys... or contribute. Cask still doesn't have reinstall/upgrade. As far as I know, Homebrew can't upgrade packages with head versions, and, worst pain of all - Homebrew doesn't support Yosemite or any unreleased OS X version. Being a tool for developers primarily, all the above are must-haves!

Re: Cargo, Rust's Package Manager

#114

Post by steveklabnik »

awj wrote: post #112
steveklabnik wrote: post #80

Earlier quoted context omitted.

> which is to use the rustdoc tool to export the projects documentation as json. Side note: it already does this by defaut: http://doc.rust-lang.org/search-index.js I'm not sure if that's enough information to do this analysis, but the basics are there! I've opened an issue: https://github.com/rust-lang/cargo/issues/47

How hard would it be to get usable type signatures out of the compiler as well? It seems like diffing two sets of type signatures would capture everything but purely semantic api incompatibility. Also seems like "here's a machine-readable version of all the types in this package" is a useful thing for a compiler toolchain to produce. Because, of course, Mozilla is paying you to sit around on your hands.

It shouldn't be that bad, given the need for the compiler to export an AST.

Re: Cargo, Rust's Package Manager

#115

Post by bronson »

steveklabnik wrote: post #108
mercurial wrote: post #106

Earlier quoted context omitted.

That's one way to look at it. On the other hand, when a format presents useful, but potentially dangerous characteristics (eg, XML entities expansion), it is entirely sensible to offer a way to not take them into account.

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?

Re: Cargo, Rust's Package Manager

#116

Post by burntsushi »

nirvdrum wrote: post #66
steveklabnik wrote: post #59

Earlier quoted context omitted.

While this is true, NOTHING in Rust-land is stable yet, so it's not as big a deal.

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, including Mozilla's Heka project and CoreOS's `etcd` project.)

Re: Cargo, Rust's Package Manager

#117

Post by Sanddancer »

alextgordon wrote: post #54
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?

Ha! There is nothing well-designed about the mutually incompatible, political hell that is OS package managers. The best solution (as taken by npm, virtualenv and others) is to install libraries locally to the project that is building them. That way, package management becomes the sole concern of the build system. "Accumulation" is a good thing, it means each project has the exact version of a package that it was tes…

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 what software needs to be updated makes quite a few peoples' jobs quite a bit harder.

Re: Cargo, Rust's Package Manager

#118

Post by shadowmint »

Sanddancer wrote: post #117
alextgordon wrote: post #54

Earlier quoted context omitted.

Ha! There is nothing well-designed about the mutually incompatible, political hell that is OS package managers. The best solution (as taken by npm, virtualenv and others) is to install libraries locally to the project that is building them. That way, package management becomes the sole concern of the build system. "Accumulation" is a good thing, it means each project has the exact version of a package that it was tes…

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 the package tool, and you get out of sync.

Pillow and freetype specifically pop to mind as an irritatingly broken recent example; when freetype upgrades, perfectly working python projects suddenly stop working because the base system freetype library has been upgraded; and the pinned python libraries that depended on the previous freetype version no longer work, because they rely on the system package manager not to do stupid things.

It would be nice if you could point cargo as a 'local binary cache' to speed things up, and make them work even if the central repository goes down; and that could be package manager friendly, I imagine.

Re: Cargo, Rust's Package Manager

#119

Post by Sanddancer »

sanderjd wrote: post #44
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?

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.

Re: Cargo, Rust's Package Manager

#120

Post by hyperion2010 »

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…

Welcome to emerge @preserved-rebuild and revdep-rebuild. Still no better way has been found to date :/.
Post reply on HN