25 ms·

Announcing the new Rust package manager, Cargo

167 points by nnutter 13y ago

chrismorgan 13y ago
Initial announcement (three quarters of an hour earlier) from Brian Anderson, project leader: https://mail.mozilla.org/pipermail/rust-dev/2014-March/009087.html https://mail.mozilla.org/pipermail/rust-dev/2014-March/00908...
jeremymcanally 13y ago
Now everyone can know the joys and horrors of Bundler! ;) I kid. This announcement is very exciting for people tinkering with Rust like myself. I really like Go, but the lack of a solid package management solution that I like using is a downer. Before you rage-comment: I know how Go packages work. I know you think they're better than anything that's ever been invented. I know there are solutions out there for some portions of what I want. But nothing has been created that really works for me (yet). So, to see this development in another one of my "tinker with it but not build a ton of production quality code just yet" languages is exciting!
- chimeracoder 13y ago
  > I really like Go, but the lack of a solid package management solution that I like using is a downer. Before you rage-comment: I know how Go packages work. I know you think they're better than anything that's ever been invented. I know there are solutions out there for some portions of what I want. But nothing has been created that really works for me (yet). What is it that you do want in a Go "package manager", then? You say that you know how Go packages work, so I'm assuming it's not one of the typical misunderstandings of newcomers from the Python/Ruby/Node.js world (all 1.x code is forwards-compatible with no modifications, static linking means makes specifying versions of packages less relevant, the package/filesystem layout parallel means that vendoring project-specific forks of packages is relatively straightforward once you know how, etc.) I put "package manager" in scare quotation marks because one of the design goals of Go is essentially to render most of the functionality of such package managers irrelevant. I say this as someone who has been writing Go for work on a daily basis for over a year and half: while Go's package system isn't perfect, it's pretty damn good, and I haven't felt the need for a package manager at all ever since I learned the way things worked.
  - pcwalton 13y ago
    Well, Rust also uses static linking by default and crates are also laid out based on the filesystem [1]. But we still feel the need for a package manager... [1]: You can nest subdirectories within the package directory if you wish, to provide more fine-grained namespacing, but all source files belonging to a Rust crate must be descendants of one directory (in contrast to Go, in which the source files must be children of one directory).
  - frio 13y ago
    Version pinning. I don't want a package manager, but I do want to be able to say import ( "github.com/frio/mycoollibrary@1.2" ) ... or some such (where the tag above could be a plain old hash too). Vendoring in every library I use is not a great solution.
    - burntsushi 13y ago
      You can get something like this already with gopkg.in: http://godoc.org/gopkg.in/v1/docs#hdr-Supported_URLs http://godoc.org/gopkg.in/v1/docs#hdr-Supported_URLs (it uses tags or branch names). It should work with any GitHub repo that's using tags/branches with names conforming to semantic versioning.
      - bjeanes 13y ago
        I hadn't seen this but it seems like a really elegant solution compared to the alternatives. I look forward to trying it.
      - grey-area 13y ago
        That looks nice. Does it work with import statements though or is it only for go get?
        burntsushi 13y ago
        It has to work with import statements---that's the whole point. :-)
- stormbrew 13y ago
  Handling packages in Go is always something that stops me from going any further when I look at it. Every time I realize I won't be able to properly specify dependencies with versions or pin them (like what Bundler does) it drives me away screaming. It's only the last few years dependency hell has been resolved in other environments (like Ruby and Node, to a lesser and sometimes weirder extent Python), I don't really want to go back in time any more.
- cryptolect 13y ago
  Coming from Ruby, when I last looked at Go about 5 months ago, I was dismayed at the package management state. My specific concern was around version pinning. I'll be excited to try out Cargo when it launches.
- Argorak 13y ago
  Have you tried GPM? https://github.com/pote/gpm https://github.com/pote/gpm
- Matrixik 13y ago
  Did you check: https://code.google.com/p/go-wiki/wiki/PackageManagementTools https://code.google.com/p/go-wiki/wiki/PackageManagementTool... ?
gleenn 13y ago
Good thing Yehuda has his phone number there so people can make sure to contact him directly with their input. I am very excited though honestly, I think he did amazing work with Bundler and is quite smart so I'm sure we'll get something quite useable.
- wycats 13y ago
  I have included my phone number on virtually every piece of public email (to mailing lists) I have ever written. I have found that people do not abuse it.
  - gleenn 13y ago
    That's pretty amazing about the phone number honestly. I meant it only in jest. Having sat in a room with you at Pivotal and hear you talk about your work on Bundler was very cool and I appreciate your work. I know you take feedback seriously so I guess its not that surprising.
molecule 13y ago
Yehuda's taking on another major software project before Rails.app [0] / Tokaido [1] is released? It's been 22 months since it raised twice its initial goal. [0] https://www.kickstarter.com/projects/1397300529/railsapp https://www.kickstarter.com/projects/1397300529/railsapp [1] https://github.com/tokaido/tokaidoapp https://github.com/tokaido/tokaidoapp
- deleted 13y ago
  [deleted]
  - chc 13y ago
    Bundler, Merb, Rails 3, Handlebars, Ember and now Cargo?
    - evilduck 13y ago
      Thor, jQuery...
      - VeejayRampay 13y ago
        W3C's Technical Architecture Group... The man has officially solved the 24-hour day problem.
- wycats 13y ago
  @molecule Fair question. Tokaido ended up taking far longer than I expected (a big, huge mea culpa for sure). TL;DR: At long last, I plan to ship Tokaido, along with a website, documentation and automation at RailsConf this year. That wouldn't be the first time I said such a thing, but the feature set is actually done (and working on many test machines). I dedicated a bunch of medium-time months at the beginning of the project to getting the initial set of functionality done: * Figuring out how to statically build Ruby, which has required non-trivial updates with every version of Ruby, and a bunch of work to get some of those fixes upstream. Many of the projects that bundle Sass or Compass in a pretty GUI are making use of this initial work. * Building a number of OSS libraries (https://github.com/tokaido https://github.com/tokaido) that enabled an application-isolated workflow like Pow with many fewer failure modes. * Integration with popular tools that people use in development (redis-server and Postgres.app) This process took longer than I expected (a year, rather than more like six months), and at the end of it, I had run out of work-time time to devote to the project. I turned my attention to nurturing a small community of people who could make Tokaido an open-source project that could be community maintained once we ship. Andrés Robalino, in particular, helped me squash a number of important bugs that I was having trouble with (including a bug that was triggering occasional 100% CPU usage on some machines), and has cleaned up the process of building static Ruby and added a bunch of polish to the UI. Tokaido has definitely not been my finest, quickest open-source turnaround, and it's fair for people who don't like me to use it as an example of my failures. That said, I think people who follow me know that I have committed my heart and soul to many more projects than Tokaido, many of which have large communities of people who love them. Not everybody needs to love my projects or my style. I should have shipped Tokaido earlier, and for that I am sorry. That said, I am committed to finishing the job with Tokaido, and believe that the other major projects I have worked on speak for themselves.
defen 13y ago
I just hope they don't repeat all the bundler-related things that made me hate deploying rails.
- steveklabnik 13y ago
  Could you expand on that, please? I am very emphatically _not_ saying that you're wrong, but without enumerating what your problems are, you can't get them solved.
  - defen 13y ago
    It's been a while (almost 2 years) and I don't use ruby much any more, so my memory is a little hazy and for all I know the issues have been fixed. My main complaints were that too much magic made it difficult to tell what was being loaded from where; and that it was a ton of work to get proper automated deployments set up (with puppet...in a way that didn't make assumptions about the target machine - RVM was also a huge culprit here). Also, at times it was painfully slow. To be fair I'm not super familiar with the internals - it's totally possible that it's all ruby's fault and any ruby package manager would have the same issues. For every day development bundler was mostly great - it was just painful to get proper deployments working. I much prefer how npm handles things.
    - steveklabnik 13y ago
      Things have changed quite a bit in the last two years. Especially around speed. So things are a lot better now in Bundler land, and should be better with Cargo, too. Cool. > I much prefer how npm handles things. Can you elaborate on how npm handles things in a better way?
      - TheHydroImpulse 13y ago
        For one, I love local by default. Having a package manager that deals with a global context makes things considerably more complex. Having everything local allows you to isolate one crate's (if we're speaking in Rust terms) dependencies to another crates' dependencies. NPM also has the ability to have isolated dependencies from each other dependency. For example, module A can pin module B to version 2, whereas module C can pin module B to version 3. So you have independent copies. Now, that worked for a dynamic language where you don't have to deal with static/dynamic linking. Would it be appropriate to statically link two modules that are the same, but at different versions? Maybe not. That would lead to massive binary sizes.
deleted 13y ago
[deleted]
teacup50 13y ago
A suggestion: don't build an OS package manager. Build a project dependency manager.
- steveklabnik 13y ago
  That's exactly what Bundler is, and what cargo will be too.
dubcanada 13y ago
I'm all for Rust package system. But Rust isn't even stable or sort of stable yet? What is the point of working on a package manager when they don't even know what vectors or the extern crate/mod system will look like in 3 months?
- pcwalton 13y ago
  We do know what those two things will look like. The design is fairly ironed out at the moment, just not fully implemented. For vectors (dynamically-sized types), there's even a PLT Redex model to verify that the design holds together…
  - carterschonwald 13y ago
    ooo, wheres this vector model?
    - kibwen 13y ago
      This is the only one that I know of, not sure if it's the one pcwalton was referring to: https://github.com/nikomatsakis/rust-redex https://github.com/nikomatsakis/rust-redex
      - bjz_ 13y ago
        Awesome! Will have to delve into this later... a formal proof is going to be super important for Rust.
      - dbaupp 13y ago
        https://github.com/anasazi/rust-redex https://github.com/anasazi/rust-redex is more recent and is actively being worked on (by ecr on IRC).
- wycats 13y ago
  A package manager will be a forcing function for stability. The Rust team wants to ship Rust 1.0 sometime late this year (I think? Correct me if I'm wrong) Building a package manager is not a one-month project, and getting it done in parallel with the stabilization of the core means that there will be a full-stack system that people can use and help iterate on as things stabilize, and that will be ready to go once Rust itself is ready for mass consumption.
vlucas 13y ago
So does this mean we're going to have to type "cargo exec" before each and every useful command now?
- deleted 13y ago
  [deleted]
- carllerche 13y ago
  a) no to cargo exec b) If you have a better solution for bundler, please open an issue and suggest it. c) There are few simple solutions to avoid `bundle exec`, which is mostly there to make things easier when getting started. I'm sure you spent a few moments to get to know your tools, so you must already be aware of these.
copx 13y ago
I am very skeptical about this. Every language which needs a "package manager" tends to make building standalone applications painful. I do think C++ is in dire need of being replaced, it is unsafe at any speed and full of legacy cruft. Unfortunately D jumped on the GC train and had other serious issues as well, allowing C++ to survive that attempt without a scratch. Rust finally did the right thing, aiming for the same zero overhead/you only pay for what you use design which made C++ such a success. However, C++ is a platform agnostic language, while Rust thus far has only supported Linux as a first class platform. I find the attitude of the Rust devs ("we will improve Windows support once the language is stable") deeply misguided. It meant that they largely missed out on feedback from Windows developers during the development of the language. "Windows developers" also means all the AAA PC(+console) game developers (the most diehard C++ users). Linux still is not a relevant platform there. And the Rust developers seem to continue to go down that rabbit hole by enlisting Ruby developers to develop a "package manager". As a Windows guy the very word makes me cringe. How is that thing going to integrate with Visual Studio and other Windows specific concerns? Ruby only really works on Linux, first advice you get as a Windows guy wanting to learn Ruby is "Install Linux, if you try to do Ruby development on Windows you are in for a world of pain". I do not trust any Ruby developer to write portable software, they are married to the GNU/Linux ecosystem. Would you expect Microsoft guys to develop something which actually works well on Linux? Also remember that C++ does not have a "package manager". Some of the most complex and massive applications in the world are written in C++, yet you do not hear many C++ developers crying "When will we finally get a package manager?". It is not even on the agenda. C does not have one either. "Package managers" are a Linux-ism, they deliver a certain UX you may or may not like (personally I hate it with passion), but they should not be part of a platform agnostic programming language. A package manager may belong to a Linux development environment for Rust, but the language itself and its library handling should be completely independent of it. Rust libraries should work just like C++ libraries so that they do integrate well with other development environments. I see Rust becoming a new OCaml, utterly Linux-centric and thus leaving C++ as the sole competitor in the maximal performance + high-level abstractions + platform agnostic category. For the sake of games no longer crashing randomly because of memory corruption bugs: change course now.
- dbaupp 13y ago
moron4hire 13y ago
For Rust, this is good. I'm sure this is very good for Rust. Take the rest of my message with a grain of salt. It's 6:30am and I'm working through my first cup of coffee still. I'm not intentionally trying to be a grumpy old man. For the rest of us, I'm concerned that yet-another-package-manager (YAPM? Yap-meager?) will just continue to fracture the library ecosystem. Why can't something like APT handle it? NPM doesn't work the same as PIP, doesn't work the same as Nuget, doesn't work the same as Gem, other than the most basic install functionality. Packaging libraries for distribution is different for each, and if you have a problem, tearing into the system to figure out where the failure occurred is different for each. Maybe it's because, through hard-fought experience, I've finally learned how to manage .NET dependencies without too much headache. Don't ever even think of trying to use the GAC. Don't let your developers install the dependencies on their own. Just make a directory full of DLLs in your project root and use relative paths to load them. It's the only way I've been able to get developers up and running with a project in Visual Studio as soon as they clone the repository. Even Nuget gave me issues (though granted, I gave up on it so fast I don't remember what they were, other than telling the jr. dev to just dump the DLL in the libs directory already and get to work on the issue list). Attempting to isolate your library ecosystem from the file system feels like it encourages "reinventing the wheel" at the language level for libraries that will mostly be the same across platforms. Do we really need to figure out how to do database connections in yet another language? Why are there 15 different syntaxes for positional arguments in strings? I'm just getting a little... weary... of starting to learn a new programming and spending the next few hours just figuring out that they've renamed printf to writeln and %s to {0} for no good reason, or that there are no database connectors yet, or if there are they only implement a strange subset of databases. It almost feels like language devs have gone out of their way to be superficially different from everyone else, without being substantially different. Given that most languages have support for some kind of foreign function interface, especially with the C ABI, it seems like we have the tools available to us to start building cross-platform libraries and distribute them regardless of consuming language. I've been wanting to dabble in Rust for a little while, but damn, yet another package manager to learn, yet another notion of what a library ecosystem should look like, just doesn't excite me right now. It's time I will have to spend to get in the door, and I am not even sure right now if I will want to stick around. But I suppose with an initiative like Rust, isolation is probably the correct ideology, considering it's about security/performance before productivity. Anyway, complaining done. No hate for Rust-team's work. Just kind of yearning for a probably unobtainable utopian future :/
davidgerard 13y ago
Every application expands until it contains a sketchy rewrite of apt-get. I BEG YOU as a sysadmin: make sure this stuff is compatible with Debian packaging. Please. Please.
- byroot 13y ago
  I don't know much about Rust, but AFAIK it's mostly static linking like Go. So 2 Rust applications won't have to share anything, so developments packages do not have to be converted into deb packages. Unlike ruby or python packages.
  - davidgerard 13y ago
    I fear it'll be one of those things where "can" becomes "must".
  - mcguire 13y ago
    "I don't know much about Rust, but AFAIK it's mostly static linking like Go." Afraid not, at least by default.
    - azth 13y ago
      It is: https://news.ycombinator.com/item?id=7419980 https://news.ycombinator.com/item?id=7419980
      - mcguire 13y ago
        Weird. I have one program here using libstd-3e5aeb83-0.9.so, libgreen-83b1c0e5-0.9.so, librustuv-2ba3695a-0.9.so, libcombinations-6b2260d9-1.0.so, and libbisect-441e5ec3-1.0.so (the last two are local libraries). And I have another that doesn't, according to ldd. Both compiled with the same flags.
gkya 13y ago
Package managers make everything way more complex than they are supposed to be. I see package managers as a component of an operating system. The proper way of packaging software source is having it contained in a directory tree with one, public build script (a Makefile, a shell script...) at its root. One or many build artefacts are generated, which at user's disposal. With language specific build systems, this process gets more complicated. They disallow the user to arrange their source tree the way they want, customise the build process, and make the whole thing as convenient as running make, or e.g. ./build.sh. Provided a conventional compiler command (e.g. the cc interface), it is easy to create a Makefile that exploits it. I have had a lot of confusion with Go compiler, when I tried to build and use a checked-in, external package. Python's pip is quite complicated. Cabal, can easily be replaced with a bunch of Makefiles. Binary packages can be supplied as [tar/zip] archives, and users would eventually package them for their OS. Also, most these package managers are exploited for installing applications, which is problematic. I have not used Rust, but I will try it out. The package manager, though, is not just a bad idea, but also an inconvenience.
dllthomas 13y ago
What edge does Cargo have on Nix?

167 points by nnutter 13y ago

Initial announcement (three quarters of an hour earlier) from Brian Anderson, project leader: https://mail.mozilla.org/pipermail/rust-dev/2014-March/009087.html https://mail.mozilla.org/pipermail/rust-dev/2014-March/00908...

jeremymcanally 13y ago

Now everyone can know the joys and horrors of Bundler! ;) I kid. This announcement is very exciting for people tinkering with Rust like myself. I really like Go, but the lack of a solid package management solution that I like using is a downer. Before you rage-comment: I know how Go packages work. I know you think they're better than anything that's ever been invented. I know there are solutions out there for some portions of what I want. But nothing has been created that really works for me (yet). So, to see this development in another one of my "tinker with it but not build a ton of production quality code just yet" languages is exciting!

chimeracoder 13y ago
> I really like Go, but the lack of a solid package management solution that I like using is a downer. Before you rage-comment: I know how Go packages work. I know you think they're better than anything that's ever been invented. I know there are solutions out there for some portions of what I want. But nothing has been created that really works for me (yet). What is it that you do want in a Go "package manager", then? You say that you know how Go packages work, so I'm assuming it's not one of the typical misunderstandings of newcomers from the Python/Ruby/Node.js world (all 1.x code is forwards-compatible with no modifications, static linking means makes specifying versions of packages less relevant, the package/filesystem layout parallel means that vendoring project-specific forks of packages is relatively straightforward once you know how, etc.) I put "package manager" in scare quotation marks because one of the design goals of Go is essentially to render most of the functionality of such package managers irrelevant. I say this as someone who has been writing Go for work on a daily basis for over a year and half: while Go's package system isn't perfect, it's pretty damn good, and I haven't felt the need for a package manager at all ever since I learned the way things worked.
- pcwalton 13y ago
  Well, Rust also uses static linking by default and crates are also laid out based on the filesystem [1]. But we still feel the need for a package manager... [1]: You can nest subdirectories within the package directory if you wish, to provide more fine-grained namespacing, but all source files belonging to a Rust crate must be descendants of one directory (in contrast to Go, in which the source files must be children of one directory).
- frio 13y ago
  Version pinning. I don't want a package manager, but I do want to be able to say import ( "github.com/frio/mycoollibrary@1.2" ) ... or some such (where the tag above could be a plain old hash too). Vendoring in every library I use is not a great solution.
  - burntsushi 13y ago
    You can get something like this already with gopkg.in: http://godoc.org/gopkg.in/v1/docs#hdr-Supported_URLs http://godoc.org/gopkg.in/v1/docs#hdr-Supported_URLs (it uses tags or branch names). It should work with any GitHub repo that's using tags/branches with names conforming to semantic versioning.
    - bjeanes 13y ago
      I hadn't seen this but it seems like a really elegant solution compared to the alternatives. I look forward to trying it.
    - grey-area 13y ago
      That looks nice. Does it work with import statements though or is it only for go get?
      - burntsushi 13y ago
        It has to work with import statements---that's the whole point. :-)
stormbrew 13y ago
Handling packages in Go is always something that stops me from going any further when I look at it. Every time I realize I won't be able to properly specify dependencies with versions or pin them (like what Bundler does) it drives me away screaming. It's only the last few years dependency hell has been resolved in other environments (like Ruby and Node, to a lesser and sometimes weirder extent Python), I don't really want to go back in time any more.
cryptolect 13y ago
Coming from Ruby, when I last looked at Go about 5 months ago, I was dismayed at the package management state. My specific concern was around version pinning. I'll be excited to try out Cargo when it launches.
Argorak 13y ago
Have you tried GPM? https://github.com/pote/gpm https://github.com/pote/gpm
Matrixik 13y ago
Did you check: https://code.google.com/p/go-wiki/wiki/PackageManagementTools https://code.google.com/p/go-wiki/wiki/PackageManagementTool... ?

gleenn 13y ago

Good thing Yehuda has his phone number there so people can make sure to contact him directly with their input. I am very excited though honestly, I think he did amazing work with Bundler and is quite smart so I'm sure we'll get something quite useable.

wycats 13y ago
I have included my phone number on virtually every piece of public email (to mailing lists) I have ever written. I have found that people do not abuse it.
- gleenn 13y ago
  That's pretty amazing about the phone number honestly. I meant it only in jest. Having sat in a room with you at Pivotal and hear you talk about your work on Bundler was very cool and I appreciate your work. I know you take feedback seriously so I guess its not that surprising.

molecule 13y ago

Yehuda's taking on another major software project before Rails.app [0] / Tokaido [1] is released? It's been 22 months since it raised twice its initial goal. [0] https://www.kickstarter.com/projects/1397300529/railsapp https://www.kickstarter.com/projects/1397300529/railsapp [1] https://github.com/tokaido/tokaidoapp https://github.com/tokaido/tokaidoapp

deleted 13y ago
[deleted]
- chc 13y ago
  Bundler, Merb, Rails 3, Handlebars, Ember and now Cargo?
  - evilduck 13y ago
    Thor, jQuery...
    - VeejayRampay 13y ago
      W3C's Technical Architecture Group... The man has officially solved the 24-hour day problem.
wycats 13y ago
@molecule Fair question. Tokaido ended up taking far longer than I expected (a big, huge mea culpa for sure). TL;DR: At long last, I plan to ship Tokaido, along with a website, documentation and automation at RailsConf this year. That wouldn't be the first time I said such a thing, but the feature set is actually done (and working on many test machines). I dedicated a bunch of medium-time months at the beginning of the project to getting the initial set of functionality done: * Figuring out how to statically build Ruby, which has required non-trivial updates with every version of Ruby, and a bunch of work to get some of those fixes upstream. Many of the projects that bundle Sass or Compass in a pretty GUI are making use of this initial work. * Building a number of OSS libraries (https://github.com/tokaido https://github.com/tokaido) that enabled an application-isolated workflow like Pow with many fewer failure modes. * Integration with popular tools that people use in development (redis-server and Postgres.app) This process took longer than I expected (a year, rather than more like six months), and at the end of it, I had run out of work-time time to devote to the project. I turned my attention to nurturing a small community of people who could make Tokaido an open-source project that could be community maintained once we ship. Andrés Robalino, in particular, helped me squash a number of important bugs that I was having trouble with (including a bug that was triggering occasional 100% CPU usage on some machines), and has cleaned up the process of building static Ruby and added a bunch of polish to the UI. Tokaido has definitely not been my finest, quickest open-source turnaround, and it's fair for people who don't like me to use it as an example of my failures. That said, I think people who follow me know that I have committed my heart and soul to many more projects than Tokaido, many of which have large communities of people who love them. Not everybody needs to love my projects or my style. I should have shipped Tokaido earlier, and for that I am sorry. That said, I am committed to finishing the job with Tokaido, and believe that the other major projects I have worked on speak for themselves.

defen 13y ago

I just hope they don't repeat all the bundler-related things that made me hate deploying rails.

steveklabnik 13y ago
Could you expand on that, please? I am very emphatically _not_ saying that you're wrong, but without enumerating what your problems are, you can't get them solved.
- defen 13y ago
  It's been a while (almost 2 years) and I don't use ruby much any more, so my memory is a little hazy and for all I know the issues have been fixed. My main complaints were that too much magic made it difficult to tell what was being loaded from where; and that it was a ton of work to get proper automated deployments set up (with puppet...in a way that didn't make assumptions about the target machine - RVM was also a huge culprit here). Also, at times it was painfully slow. To be fair I'm not super familiar with the internals - it's totally possible that it's all ruby's fault and any ruby package manager would have the same issues. For every day development bundler was mostly great - it was just painful to get proper deployments working. I much prefer how npm handles things.
  - steveklabnik 13y ago
    Things have changed quite a bit in the last two years. Especially around speed. So things are a lot better now in Bundler land, and should be better with Cargo, too. Cool. > I much prefer how npm handles things. Can you elaborate on how npm handles things in a better way?
    - TheHydroImpulse 13y ago
      For one, I love local by default. Having a package manager that deals with a global context makes things considerably more complex. Having everything local allows you to isolate one crate's (if we're speaking in Rust terms) dependencies to another crates' dependencies. NPM also has the ability to have isolated dependencies from each other dependency. For example, module A can pin module B to version 2, whereas module C can pin module B to version 3. So you have independent copies. Now, that worked for a dynamic language where you don't have to deal with static/dynamic linking. Would it be appropriate to statically link two modules that are the same, but at different versions? Maybe not. That would lead to massive binary sizes.

deleted 13y ago

[deleted]

teacup50 13y ago

A suggestion: don't build an OS package manager. Build a project dependency manager.

steveklabnik 13y ago
That's exactly what Bundler is, and what cargo will be too.

dubcanada 13y ago

I'm all for Rust package system. But Rust isn't even stable or sort of stable yet? What is the point of working on a package manager when they don't even know what vectors or the extern crate/mod system will look like in 3 months?

pcwalton 13y ago
We do know what those two things will look like. The design is fairly ironed out at the moment, just not fully implemented. For vectors (dynamically-sized types), there's even a PLT Redex model to verify that the design holds together…
- carterschonwald 13y ago
  ooo, wheres this vector model?
  - kibwen 13y ago
    This is the only one that I know of, not sure if it's the one pcwalton was referring to: https://github.com/nikomatsakis/rust-redex https://github.com/nikomatsakis/rust-redex
    - bjz_ 13y ago
      Awesome! Will have to delve into this later... a formal proof is going to be super important for Rust.
    - dbaupp 13y ago
      https://github.com/anasazi/rust-redex https://github.com/anasazi/rust-redex is more recent and is actively being worked on (by ecr on IRC).
wycats 13y ago
A package manager will be a forcing function for stability. The Rust team wants to ship Rust 1.0 sometime late this year (I think? Correct me if I'm wrong) Building a package manager is not a one-month project, and getting it done in parallel with the stabilization of the core means that there will be a full-stack system that people can use and help iterate on as things stabilize, and that will be ready to go once Rust itself is ready for mass consumption.

vlucas 13y ago

So does this mean we're going to have to type "cargo exec" before each and every useful command now?

deleted 13y ago
[deleted]
carllerche 13y ago
a) no to cargo exec b) If you have a better solution for bundler, please open an issue and suggest it. c) There are few simple solutions to avoid `bundle exec`, which is mostly there to make things easier when getting started. I'm sure you spent a few moments to get to know your tools, so you must already be aware of these.

copx 13y ago

I am very skeptical about this. Every language which needs a "package manager" tends to make building standalone applications painful. I do think C++ is in dire need of being replaced, it is unsafe at any speed and full of legacy cruft. Unfortunately D jumped on the GC train and had other serious issues as well, allowing C++ to survive that attempt without a scratch. Rust finally did the right thing, aiming for the same zero overhead/you only pay for what you use design which made C++ such a success. However, C++ is a platform agnostic language, while Rust thus far has only supported Linux as a first class platform. I find the attitude of the Rust devs ("we will improve Windows support once the language is stable") deeply misguided. It meant that they largely missed out on feedback from Windows developers during the development of the language. "Windows developers" also means all the AAA PC(+console) game developers (the most diehard C++ users). Linux still is not a relevant platform there. And the Rust developers seem to continue to go down that rabbit hole by enlisting Ruby developers to develop a "package manager". As a Windows guy the very word makes me cringe. How is that thing going to integrate with Visual Studio and other Windows specific concerns? Ruby only really works on Linux, first advice you get as a Windows guy wanting to learn Ruby is "Install Linux, if you try to do Ruby development on Windows you are in for a world of pain". I do not trust any Ruby developer to write portable software, they are married to the GNU/Linux ecosystem. Would you expect Microsoft guys to develop something which actually works well on Linux? Also remember that C++ does not have a "package manager". Some of the most complex and massive applications in the world are written in C++, yet you do not hear many C++ developers crying "When will we finally get a package manager?". It is not even on the agenda. C does not have one either. "Package managers" are a Linux-ism, they deliver a certain UX you may or may not like (personally I hate it with passion), but they should not be part of a platform agnostic programming language. A package manager may belong to a Linux development environment for Rust, but the language itself and its library handling should be completely independent of it. Rust libraries should work just like C++ libraries so that they do integrate well with other development environments. I see Rust becoming a new OCaml, utterly Linux-centric and thus leaving C++ as the sole competitor in the maximal performance + high-level abstractions + platform agnostic category. For the sake of games no longer crashing randomly because of memory corruption bugs: change course now.

dbaupp 13y ago

moron4hire 13y ago

For Rust, this is good. I'm sure this is very good for Rust. Take the rest of my message with a grain of salt. It's 6:30am and I'm working through my first cup of coffee still. I'm not intentionally trying to be a grumpy old man. For the rest of us, I'm concerned that yet-another-package-manager (YAPM? Yap-meager?) will just continue to fracture the library ecosystem. Why can't something like APT handle it? NPM doesn't work the same as PIP, doesn't work the same as Nuget, doesn't work the same as Gem, other than the most basic install functionality. Packaging libraries for distribution is different for each, and if you have a problem, tearing into the system to figure out where the failure occurred is different for each. Maybe it's because, through hard-fought experience, I've finally learned how to manage .NET dependencies without too much headache. Don't ever even think of trying to use the GAC. Don't let your developers install the dependencies on their own. Just make a directory full of DLLs in your project root and use relative paths to load them. It's the only way I've been able to get developers up and running with a project in Visual Studio as soon as they clone the repository. Even Nuget gave me issues (though granted, I gave up on it so fast I don't remember what they were, other than telling the jr. dev to just dump the DLL in the libs directory already and get to work on the issue list). Attempting to isolate your library ecosystem from the file system feels like it encourages "reinventing the wheel" at the language level for libraries that will mostly be the same across platforms. Do we really need to figure out how to do database connections in yet another language? Why are there 15 different syntaxes for positional arguments in strings? I'm just getting a little... weary... of starting to learn a new programming and spending the next few hours just figuring out that they've renamed printf to writeln and %s to {0} for no good reason, or that there are no database connectors yet, or if there are they only implement a strange subset of databases. It almost feels like language devs have gone out of their way to be superficially different from everyone else, without being substantially different. Given that most languages have support for some kind of foreign function interface, especially with the C ABI, it seems like we have the tools available to us to start building cross-platform libraries and distribute them regardless of consuming language. I've been wanting to dabble in Rust for a little while, but damn, yet another package manager to learn, yet another notion of what a library ecosystem should look like, just doesn't excite me right now. It's time I will have to spend to get in the door, and I am not even sure right now if I will want to stick around. But I suppose with an initiative like Rust, isolation is probably the correct ideology, considering it's about security/performance before productivity. Anyway, complaining done. No hate for Rust-team's work. Just kind of yearning for a probably unobtainable utopian future :/

davidgerard 13y ago

Every application expands until it contains a sketchy rewrite of apt-get. I BEG YOU as a sysadmin: make sure this stuff is compatible with Debian packaging. Please. Please.

byroot 13y ago
I don't know much about Rust, but AFAIK it's mostly static linking like Go. So 2 Rust applications won't have to share anything, so developments packages do not have to be converted into deb packages. Unlike ruby or python packages.
- davidgerard 13y ago
  I fear it'll be one of those things where "can" becomes "must".
- mcguire 13y ago
  "I don't know much about Rust, but AFAIK it's mostly static linking like Go." Afraid not, at least by default.
  - azth 13y ago
    It is: https://news.ycombinator.com/item?id=7419980 https://news.ycombinator.com/item?id=7419980
    - mcguire 13y ago
      Weird. I have one program here using libstd-3e5aeb83-0.9.so, libgreen-83b1c0e5-0.9.so, librustuv-2ba3695a-0.9.so, libcombinations-6b2260d9-1.0.so, and libbisect-441e5ec3-1.0.so (the last two are local libraries). And I have another that doesn't, according to ldd. Both compiled with the same flags.

gkya 13y ago

Package managers make everything way more complex than they are supposed to be. I see package managers as a component of an operating system. The proper way of packaging software source is having it contained in a directory tree with one, public build script (a Makefile, a shell script...) at its root. One or many build artefacts are generated, which at user's disposal. With language specific build systems, this process gets more complicated. They disallow the user to arrange their source tree the way they want, customise the build process, and make the whole thing as convenient as running make, or e.g. ./build.sh. Provided a conventional compiler command (e.g. the cc interface), it is easy to create a Makefile that exploits it. I have had a lot of confusion with Go compiler, when I tried to build and use a checked-in, external package. Python's pip is quite complicated. Cabal, can easily be replaced with a bunch of Makefiles. Binary packages can be supplied as [tar/zip] archives, and users would eventually package them for their OS. Also, most these package managers are exploited for installing applications, which is problematic. I have not used Rust, but I will try it out. The package manager, though, is not just a bad idea, but also an inconvenience.

dllthomas 13y ago

What edge does Cargo have on Nix?