[rust-dev] Deprecating rustpkg

Gaetan gaetan at xeberon.net
Tue Jan 28 01:32:28 PST 2014


I also agree on the task force proposal, it's the right way to capitalize
on past failure and success.

For me, rust-pkg will not success if it doesn't have a proper centralized
repository. That's a debate, the current version explicitely specify the
URL where to download stuff. But things changes, developers changes, URL
get broken, or a new developer forks a project or continue it on another
repository.

I have quite a good experience (I think) on dependency management, mostly
on C++ (QT/Linux projects and embedded) and now python (that's why I love
the simplicity and power of pipy!) so I would be glad to be associated with
such task force. For me you have two approach: "enough for major use case",
things like pipy that do the job for most use case, and "exhaustive
approach" where you end up with complicated but extremely powerful
do-it-all tools like maven but that get eventually dropped because it's too
complex to use.

That is also joining the build system thread, where also rustpkg appeared
:) But I push to split them appart: the dependency management tool should
trigger a build system and not do everything

-----
Gaetan



2014-01-28 Huon Wilson <dbau.pp at gmail.com>

> On 28/01/14 19: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.
>>
>
> rustpkg (theoretically) manages fetching and building dependencies (with
> the appropriate versions), as well as making sure those dependencies can be
> found (i.e. what the -L flag does for rustc).
>
>
>
>> 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.
>>
>>
> rustpkg is unfinished and has several bugs, so describing its current
> behaviour/usage as if it were its intended behaviour/usage is not correct.
> I believe it was designed to handle native (non-Rust) dependencies to some
> degree.
>
>
> Huon
>
>
>
>  [Disclaimer: I've never quite got a rustpkg workflow going. It's probably
>> awesome, but completely overshadowed by `rustc`.]
>>
>> On 01/28/2014 09:02 AM, Tim Chevalier wrote:
>>
>>> On Mon, Jan 27, 2014 at 10:20 PM, Val Markovic <val at markovic.io> wrote:
>>>
>>>>
>>>> On Jan 27, 2014 8:53 PM, "Jeremy Ong" <jeremycong at gmail.com> 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'd like to second this request. I haven't used rustpkg myself but I've
>>>> read
>>>> its reference manual (
>>>> https://github.com/mozilla/rust/blob/master/doc/rustpkg.md) and it
>>>> sounds
>>>> like a reasonable design. Again, since I haven't used it, I'm sure I'm
>>>> missing some obvious flaws.
>>>>
>>>
>>> Thirded. I implemented rustpkg as it's currently known, and did so in
>>> the open, detailing what I was thinking about in a series of
>>> exhaustively detailed blog posts. Since few people seemed very
>>> interested in providing feedback on it as I was developing it (with
>>> the exception of Graydon, who also worked on the initial design), I
>>> assumed that it was on the right track. I rewrote rustpkg because
>>> there was a perception that the initial design of rustpkg was not on
>>> the right track, nor was cargo, but obviously simply rewriting the
>>> whole system from scratch in the hopes that it would be better didn't
>>> work, since people are talking about throwing it out. So, before
>>> anybody embarks on a third rewrite in the hopes that *that* will be
>>> better, I suggest that a working group form to look at what went wrong
>>> in the past 2 or 3 attempts at implementing a build system / package
>>> system for Rust, so that those mistakes can be learned from. Perhaps
>>> all that needs to be done differently is that someone more central to
>>> the community needs to write it, but if that's what it takes, it seems
>>> preferable to the wasted time and effort that I imagine will ensue
>>> from yet another rewrite for the sake of throwing out code.
>>>
>>> Cheers,
>>> Tim
>>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140128/7810316e/attachment-0001.html>


More information about the Rust-dev mailing list