[rust-dev] Deprecating rustpkg

Jeremy Ong jeremycong at gmail.com
Tue Jan 28 01:42:31 PST 2014


Rubygems is, in my opinion, one of the best examples of package managers
for a programming language out there. I don't use ruby currently but I
recall liking it much more than the competition, at least as of a few years
ago. In no particular order, it features:

- central repository
- optionally specify alternative urls on a per package basis
- hard and soft version requirements
- local bundles (so you can have multiple versions of the same package and
switch seamlessly from project to project)
- dependency calculation
- dependency groups (i.e. ability to group a number of deps in a "test"
group which can be switched on or off)
- local or systemwide install of libraries and executables
- easy to write a package and publish it (very easy)
- gem signing
- plugin system that allowed extensions to be written (an example plugin
was something that allowed a gem to be compiled with specific ruby versions
iirc)
- with the bundler gem, an easy way to at a glance, examine all
dependencies of a given project and fetch them all (the Gemfile). This had
implications to deploy processes too (gemfile.lock).

This isn't a comprehensive list but it evidently made an impression on me.
I'm sure there are tons of other things I'm missing. Other systems that
I've worked with I found critically lacking in isolating the dependencies
of one project from another or failing to resolve dependency trees
satisfactorily. Most importantly, the ease with which packages could be
downloaded and used immediately were immense.

As mentioned before, getting this right is crucial to establishing a
vibrant developer ecosystem (see rubygems and npm).


On Tue, Jan 28, 2014 at 1:33 AM, Lee Braiden <leebraid at gmail.com> wrote:

> On 28/01/14 08:36, György Andrasek wrote:
>
>> I never quite understood the problem `rustpkg` was meant to solve. For
>> building Rust code, `rustc --out-dir build` is good enough. For running
>> tests and benchmarks, `rustc` is good enough. For downloading things, I
>> still need to feed it a github address, which kinda takes away any value it
>> could have over `git clone` or git submodules.
>>
>> What I would actually need from a build system, i.e. finding {C,C++,Rust}
>> libraries, building {C,C++,Rust} libraries/executables and linking them to
>> said {C,C++,Rust} libraries, it doesn't do. It also doesn't bootstrap rustc.
>>
>
> I agree with this.  What I'd want is much more like apt (add repositories,
> update lists of available packages from those repositories, manage
> priorities between repositories, say that one repository should be
> preferred over another for a particular package, working in specific
> prefixes (/usr/local, /usr, /, ~/Projects/something-requiring-old-libs),
> but rust-specific and platform independent.
>
>
> --
> Lee
>
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140128/2f489e95/attachment.html>


More information about the Rust-dev mailing list