[rust-dev] Deprecating rustpkg

Chip Collier photex at gmail.com
Wed Jan 29 10:57:35 PST 2014


Hi everyone,

I am new here so please forgive my ignorance of previous efforts and any
discussions leading up to rustpkg in it's current form. I also don't have
extensive experience with rustpkg itself having arrived at time when the
message was basically "don't use rustpkg, just use make". I hope I'm not
out of line with my questions and opinions here.

Because I'm new and I'm very interested in the subject it would be
tremendously useful for me to hear precisely what is so bad about rustpkg
that its problems preclude any salvage or redesign.  If we don't want to do
this on the mailing list there could always be a "rustpkg postmortem" wiki
page. It would also be helpful to know if those in favor of removal and
those in favor of finishing it also agree on what exactly it should do.

Has there been any concentrated review of the state of the art for other
languages/toolkits/ecosystems? Is there any reason not to extend an
existing solution? Gradle for example states that the entire goal of the
project is to be the ultimate tool for any project and already has early
support for building native projects in assembly, C, or C++. Why not add a
toolkit plugin for rustc? I understand that it would be less than ideal to
require a JVM to use the defacto Rust build and packaging tool but the
point I'm trying to make is that if correcting and completing rustpkg isn't
on the table, then where can we look for a head start into a solution that
appeals to the most people?

The rest of this email might be off-topic so feel free to ignore. I can
always start a new thread.

Was it ever the goal to have this tool be the entry point for peoples
interaction with Rust? "Just download X to get started!" I seem to recall
reading that there was once a "rust" as well as "rustc". Is cargo-lite.py
referring to a previous effort as well?
Could a project specify Rust version constraints and this tool fetches the
most appropriate Rust binaries (or uses a set of configured Rust
installations) for it's dependencies, using them to execute the build?
(Having to manage a large codebase that requires multiple versions of GCC
is an enormous headache for me. Rust doesn't seem to be on the same track
at all here... but oh how I hope it never becomes the same problem.)
Related to the question above, is the goal to have Rust itself packaged and
distributed with this tool?

In my experience, whatever solution is chosen needs to embrace
configuration over convention. To me this means that convention is
established through default configuration and for a majority of projects
very little will be required to be productive with the tool. For shops or
projects which need to orchestrate rather large and specific builds with
assortments of dependencies that span platforms, it's wonderful to not have
to travel outside the friendly confines of the official build and package
management tool. I would say that this also adds confidence in a new
technology to know that you won't be fighting the tools to make use of it.


Chip



On Tue, Jan 28, 2014 at 1:29 PM, Tim Chevalier <catamorphism at gmail.com>wrote:

> rustpkg is definitely unfinished. It's not clear to me that what it
> needs is to be destroyed, rather than finished. That is, there may
> well be good reasons; I just haven't seen them so far in this thread.
> The concrete points that a few people have made are ones to do with
> unfinished pieces of rustpkg that are relatively well-delineated from
> the entire system.
>
> I'm not trying to argue for keeping it, it just seems to me that for
> the good of the project, the reasons why it couldn't be salvaged
> should be documented somewhere. As the person who did most of the
> work, but wasn't able to finish it because I left Mozilla, it's
> surprising to me that the fact that rustpkg isn't finished is being
> used as a reason to purge it entirely. Rust is, after all, not
> finished yet -- as a whole -- but we're not throwing out the entire
> language.
>
> Cheers,
> Tim
>
>
> On Tue, Jan 28, 2014 at 11:28 AM, Ian Daniher <explodingmind at gmail.com>
> wrote:
> > Lots of good points in this thread, but I wanted to request deprecation,
> but
> > not removal until a better alternative is documented and made available.
> > Rustpkg works for my needs - I use it every day -  but it definitely
> needs
> > some TLC.
> >
> > Thanks!
> > --
> > Ian
> >
> >
> > On Tue, Jan 28, 2014 at 11:46 AM, SiegeLord <slabode at aim.com> wrote:
> >>
> >> On 01/27/2014 11:53 PM, Jeremy Ong wrote:
> >>>
> >>> I'm somewhat new to the Rust dev scene. Would anybody care to summarize
> >>> roughly what the deficiencies are in the existing system in the
> interest
> >>> of forward progress? It may help seed the discussion for the next
> effort
> >>> as well.
> >>
> >>
> >> I can only speak for myself, but here are some reasons why I abandoned
> >> rustpkg and switched to CMake.
> >>
> >> Firstly, and overarchingly, it was the attitude of the project
> development
> >> with respect to issues. As a comparison, let me consider Rust the
> language.
> >> It is a pain to make my code pass the borrow check sometimes, the
> lifetimes
> >> are perhaps the most frustrating aspect of Rust. I put up with them
> however,
> >> because they solve a gigantic problem and are the keystone of Rust's
> >> safety-without-GC story. rustpkg also has many incredibly frustrating
> >> aspects, but they are there (in my opinion) arbitrarily and not as a
> >> solution to any real problem. When I hit them, I do not get the same
> sense
> >> of purposeful sacrifice I get with Rust's difficult points. Let me
> outline
> >> the specific issues I personally hit (I know of other ones, but I
> haven't
> >> encountered them personally).
> >>
> >> Conflation of package id and source. That fact combined with the fact
> that
> >> to depend on some external package you have to write "extern mod =
> pkgid"
> >> meant that you needed to create bizarre directory structures to depend
> on
> >> locally developed packages (e.g. you'd have to put your locally
> developed
> >> project in a directory tree like so: github.com/SiegeLord/Project).
> This is
> >> not something I was going to do.
> >>
> >> The package dependencies are written in the source file, which makes it
> >> onerous to switch between versions/forks. A simple package script would
> have
> >> solved it, but it wasn't present by design.
> >>
> >> My repositories have multiple crates, and rustpkg is woefully
> >> under-equipped to handle that case. You cannot build them without
> dealing
> >> with pkg.rs, and using them from other projects seemed impossible too
> (the
> >> extern mod syntax wasn't equipped to handle multiple crates per
> package).
> >> This is particularly vexing when you have multiple example programs
> >> alongside your library. I was not going to split my repository up just
> >> because rustpkg wasn't designed to handle that case.
> >>
> >> All of those points would be solved by having an explicit package
> >> description file/script which was THE overarching design non-goal of
> >> rustpkg. After that was made clear to me, I just ditched it and went to
> C++
> >> style package "management" and a CMake build system.
> >>
> >> -SL
> >>
> >> _______________________________________________
> >> Rust-dev mailing list
> >> Rust-dev at mozilla.org
> >> https://mail.mozilla.org/listinfo/rust-dev
> >
> >
> >
> > _______________________________________________
> > Rust-dev mailing list
> > Rust-dev at mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
> >
>
>
>
> --
> Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
> "If you are silent about your pain, they'll kill you and say you enjoyed
> it."
> -- Zora Neale Hurston
> _______________________________________________
> 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/20140129/b7998090/attachment.html>


More information about the Rust-dev mailing list