Re: [rust-dev] Deprecating rustpkg

Further historical disambiguation: * there used to be no package manager * Cargo was created * rustpkg replaced Cargo * Cargo' replaced rustpkg Why I'm the only one who calls it Cargo', I don't know. ;D Kevin On Sat, Jun 7, 2014 at 12:38 PM, Vladimir Matveev wrote: > Hi, Fredrik, > > Cur

Re: [rust-dev] Deprecating rustpkg

Hi, Fredrik, Currently a new package manager designed specifically for Rust is under active development. It is called Cargo, and you can find it here [1]. It is pretty much in very alpha stage now, but one day it will become a full package manager and build system for Rust. [1]: https://gith

Re: [rust-dev] Deprecating rustpkg

You might want to check out this thread... Mozilla is sponsoring work on a new Rust package manager called Cargo: https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org https://

[rust-dev] Deprecating rustpkg

Hi! Seems like this thread has been dead for a while. I am new to rust, but was playing with it today, looking for rustpkg and ended up reading this thread. I have tried to read through this thread, but it is possible that there is a newer more relevant thread covering this topic in which case I

Re: [rust-dev] Deprecating rustpkg

On Tue, Feb 4, 2014 at 2:29 AM, Jordi Boggiano wrote: > I just hope whoever starts working on a new spec announces it clearly THIS -- Tony Arcieri ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Deprecating rustpkg

On 28/01/2014 12:23, Matthew Frazier wrote: Have you ever used Composer ? I know that Jordi Boggiano, one of the authors, has been involved with the Rust community in the past. Some Composer features that I think are critical for the new Rust package manager include: >

Re: [rust-dev] Deprecating rustpkg

2014-02-02 Thomas Leonard : > [ I don't want to start another argument, but since you guys are discussing > 0install, maybe I can provide some useful input... ] > > I don't follow this. Whether the developer uses 0install to get the build > dependencies doesn't make any difference to the generated

Re: [rust-dev] Deprecating rustpkg

A general observation (not particularly replying to your post, Thomas). For both python and haskell (just to name two languages), distribution (where things end up on the filesystem ready to be used) can be done by both the built-in tools (cabal-install, pip) and the distribution-specific tools. G

Re: [rust-dev] Deprecating rustpkg

[ I don't want to start another argument, but since you guys are discussing 0install, maybe I can provide some useful input... ] On 2014-02-02 07:20, Vladimir Matveev wrote: How will it handle external dependencies? I don't think it should. External dependencies are way too complex. They come

Re: [rust-dev] Deprecating rustpkg

> How will it handle external dependencies? I don't think it should. External dependencies are way too complex. They come in different flavors on different systems. On Windows, for example, you don't have a package manager, and you'll have to ship these dependencies with the program using an instal

Re: [rust-dev] Deprecating rustpkg

On Sat, Feb 1, 2014 at 4:28 PM, Vladimir Matveev > > Well, it seems that working for a long time with a code targeting virtual > machines is corrupting :) I completely forgot about different models of > compilation. I see your point. But I think that developing and distributing > should be consider

Re: [rust-dev] Deprecating rustpkg

To clarify, when I was writing "user" I meant the developer who uses this package, not the end user of complete program. > On 01/02/14 19:32, Vladimir Matveev wrote: > > When this API is used directly by the package, then the user *should* > > know about it. He's using it, after all. > > There a

Re: [rust-dev] Deprecating rustpkg

On 01/02/14 19:59, Isaac Dupree wrote: On 02/01/2014 06:27 AM, Matthieu Monrocq wrote: In short, isn't there a risk of crashes if one accidentally links two versions of a given library and start exchanging objects ? It seems impractical to prove that objects created by one version cannot acciden

Re: [rust-dev] Deprecating rustpkg

On 01/02/14 19:32, Vladimir Matveev wrote: When this API is used directly by the package, then the user *should* know about it. He's using it, after all. There are developers (direct library users), and then distro maintainers/admins/users who need to manage libraries installed on their syste

Re: [rust-dev] Deprecating rustpkg

On 02/01/2014 06:27 AM, Matthieu Monrocq wrote: In short, isn't there a risk of crashes if one accidentally links two versions of a given library and start exchanging objects ? It seems impractical to prove that objects created by one version cannot accidentally end up being passed to the other v

Re: [rust-dev] Deprecating rustpkg

> You can do that within a major version, except for one case - multiple > developers creating diverged versions of 2.13, based on 2.12, each with > their own features. > ... > But doing it per major version recursively raises the question of which > major version is authorised: what if you ha

Re: [rust-dev] Deprecating rustpkg

Just read the document at http://semver.org/ fully and this sounds like a sensible approach. Since I think with crate metadata it should be obvious (at the symbol level) if the public api changes, then this can be tracked somewhere by an automatic tool where we have a public list of rust packages (

Re: [rust-dev] Deprecating rustpkg

On 01/02/14 18:54, Gaetan wrote: why not enforcing in a way or another a API compatibility test suite for ensuring at least a certain level of compatibility between two version? I think it is something quite doable, and moreover this would kinda force the package manager to write unit tests whi

Re: [rust-dev] Deprecating rustpkg

On 01/02/14 18:54, Gaetan wrote: why not enforcing in a way or another a API compatibility test suite for ensuring at least a certain level of compatibility between two version? I think it is something quite doable, and moreover this would kinda force the package manager to write unit tests whi

Re: [rust-dev] Deprecating rustpkg

why not enforcing in a way or another a API compatibility test suite for ensuring at least a certain level of compatibility between two version? I think it is something quite doable, and moreover this would kinda force the package manager to write unit tests which is always a good practice. -

Re: [rust-dev] Deprecating rustpkg

On Fri, Jan 31, 2014 at 1:05 PM, Tony Arcieri wrote: > IMO, a system that respects semantic versioning, allows you to constrain > the dependency to a particular *major* version without requiring pinning > to a *specific* version. > > I would call anything that requires pinning to a specific versi

Re: [rust-dev] Deprecating rustpkg

Ah, this: On 01/02/14 15:43, Lee Braiden wrote: extended_begin() old_funcs() new_funcs() extended_end() should read more like: begin() old_funcs() extended_begin() new_funcs() extended_end() end() -- Lee _

Re: [rust-dev] Deprecating rustpkg

On 01/02/14 15:48, Vladimir Lushnikov wrote: I think USE flags are more appropriate for library features (which is exactly the way portage uses them). So you have your rust app with conditional code that depends on a particular cfg (https://github.com/mozilla/rust/wiki/Doc-attributes) and then

Re: [rust-dev] Deprecating rustpkg

I think USE flags are more appropriate for library features (which is exactly the way portage uses them). So you have your rust app with conditional code that depends on a particular cfg ( https://github.com/mozilla/rust/wiki/Doc-attributes) and then you expose a list of these in your package speci

Re: [rust-dev] Deprecating rustpkg

On 01/02/14 14:49, Vladimir Lushnikov wrote: Portage has a very similar syntax/way of specifying runtime vs. build-time dependencies: http://devmanual.gentoo.org/general-concepts/dependencies/. Apt doesn't have support for slots and USE flags (code that is included/excluded at compile time fo

Re: [rust-dev] Deprecating rustpkg

On 01/02/14 14:55, Vladimir Matveev wrote: Is it possible at all to find the latest version of a library which is still compatible completely automatically? Incompatibilites can be present on logic level, so the compilation wiith incompatible version will succeed, but the program will work incorr

Re: [rust-dev] Deprecating rustpkg

On 01/02/14 09:39, Gaetan wrote: There is not only API change. Sometime, from a minor version to another, a feature get silently broken (that is silent regression). While it might not impact libA which depends on it, but it may fail libB which also depends on it, but with a previous version.

Re: [rust-dev] Deprecating rustpkg

Is it possible at all to find the latest version of a library which is still compatible completely automatically? Incompatibilites can be present on logic level, so the compilation wiith incompatible version will succeed, but the program will work incorrectly. I don't think that this can be solved

Re: [rust-dev] Deprecating rustpkg

Portage has a very similar syntax/way of specifying runtime vs. build-time dependencies: http://devmanual.gentoo.org/general-concepts/dependencies/. Apt doesn't have support for slots and USE flags (code that is included/excluded at compile time for optional features). On Sat, Feb 1, 2014 at 2:3

Re: [rust-dev] Deprecating rustpkg

On 01/02/14 00:12, Tony Arcieri wrote: On Fri, Jan 31, 2014 at 4:07 PM, Vladimir Lushnikov mailto:vladi...@slate-project.org>> wrote: Just to be clear, I think what you are saying is that you want version pinning to be dynamic? I.e. when a new version of a library dependency becomes

Re: [rust-dev] Deprecating rustpkg

Oops, that should have been: 'breaking-changes ==> new package name' I disagree with the 'breaking-changes ==> new version' idea. > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Deprecating rustpkg

There are some great points here (that should probably go into some sort of 'best practices' doc for rust package authors). However there is a fundamental flaw IMO - we are talking about open-source code, where the author is not obligated to do *any* of this. Most open-source licenses explicitly s

Re: [rust-dev] Deprecating rustpkg

On 01/02/14 00:09, Tony Arcieri wrote: On Fri, Jan 31, 2014 at 4:03 PM, Lee Braiden > wrote: This would be counterproductive. If a library cannot be upgraded to 1.9, or even 2.2, because some app REQUIRES 1.4, then that causes SERIOUS, SECURITY issues. Y

Re: [rust-dev] Deprecating rustpkg

On 01/02/14 00:05, Vladimir Lushnikov wrote: I disagree. With the same analogy, I could sell you a blunt knife - you would use it as a letter opener, and then I would fix the bug. Now you might actually cut yourself! No. The correct analogy would be: 1) I create a recipe for a sharp knife.

Re: [rust-dev] Deprecating rustpkg

Just two small remarks: 1. C++11 actually introduced the idea of *inline namespace* specifically to detect the use of multiple (incompatible) versions of a single library. The *compiling* phase sees through inline namespaces as if they were not there, however the symbol get mangled differently, c

Re: [rust-dev] Deprecating rustpkg

There is not only API change. Sometime, from a minor version to another, a feature get silently broken (that is silent regression). While it might not impact libA which depends on it, but it may fail libB which also depends on it, but with a previous version. As a result, libA force installation of

Re: [rust-dev] Deprecating rustpkg

On Fri, Jan 31, 2014 at 4:23 PM, Vladimir Lushnikov < vladi...@slate-project.org> wrote: > Is this not exactly what was being discussed? > It is! I'm still asking for a less handwavy explanation of how this would work in a system which may-or-may-not select multiple versions of a package dependin

Re: [rust-dev] Deprecating rustpkg

Is this not exactly what was being discussed? Maven doesn't support this (but pip does for example ""Baz>=2.0, <3.0"). Portage certainly supports it as well. On Sat, Feb 1, 2014 at 12:15 AM, Tony Arcieri wrote: > On Fri, Jan 31, 2014 at 4:15 PM, Vladimir Lushnikov < > vladi...@slate-project.org

Re: [rust-dev] Deprecating rustpkg

On Fri, Jan 31, 2014 at 4:15 PM, Vladimir Lushnikov < vladi...@slate-project.org> wrote: > 1) To determine API compatibility for you based on some input from the > library author? (be this semantic versioning, slots, something else) > This. You should be able to lock to major and/or minor version

Re: [rust-dev] Deprecating rustpkg

The question is, what do you want the constraint-based system to do: 1) To determine API compatibility for you based on some input from the library author? (be this semantic versioning, slots, something else) 2) To determine API compatibility automatically just by examining the interface provided

Re: [rust-dev] Deprecating rustpkg

Looking briefly over the semantic versioning page, doesn't it just mandate a particular version format for when you break API compatibility? This is in theory the same thing I was talking about with slots, just encoded in the version number. It can get ridiculous as well though - see for example op

Re: [rust-dev] Deprecating rustpkg

On Fri, Jan 31, 2014 at 4:07 PM, Vladimir Lushnikov < vladi...@slate-project.org> wrote: > Just to be clear, I think what you are saying is that you want version > pinning to be dynamic? I.e. when a new version of a library dependency > becomes available, upgrade the package with that dependency?

Re: [rust-dev] Deprecating rustpkg

On Fri, Jan 31, 2014 at 4:03 PM, Lee Braiden wrote: > This would be counterproductive. If a library cannot be upgraded to 1.9, > or even 2.2, because some app REQUIRES 1.4, then that causes SERIOUS, > SECURITY issues. > Yes, these are exactly the types of problems I want to help solve. Many peo

Re: [rust-dev] Deprecating rustpkg

Apologies, that should have been *a language that I know of* On Sat, Feb 1, 2014 at 12:07 AM, Vladimir Lushnikov < vladi...@slate-project.org> wrote: > Then you would want to know about it. No package manager for a language > has a way to see security advisories (and this is a problem). > >

Re: [rust-dev] Deprecating rustpkg

Then you would want to know about it. No package manager for a language has a way to see security advisories (and this is a problem). Gentoo has GLSA which is kind of OK (better than scanning the CVE list yourself) but I feel a language should offer a tool to do exactly this. Just to be clear, I t

Re: [rust-dev] Deprecating rustpkg

I disagree. With the same analogy, I could sell you a blunt knife - you would use it as a letter opener, and then I would fix the bug. Now you might actually cut yourself! I think this is a different concern. It should be up to the library author what they deems as 'compatible'. It does not excuse

Re: [rust-dev] Deprecating rustpkg

On Fri, Jan 31, 2014 at 3:59 PM, Jack Moffitt wrote: > The algorithm here is rather simple. We try to satisfy rust-logger and > rust-rest. rust-rest has a version (or could be a tag like 1.x) so we > go get that. It depends on rust-json 2.0 so we get that. Then we try > to look for rust-logger,

Re: [rust-dev] Deprecating rustpkg

On 31/01/14 23:03, Tony Arcieri wrote: Can anyone point to a real-world example of a dependency resolver which can produce solutions which may-or-may-not contain multiple versions of the same library? This would be counterproductive. If a library cannot be upgraded to 1.9, or even 2.2, becau

Re: [rust-dev] Deprecating rustpkg

> What is this algorithm, and what is a concrete example of a set of > dependencies that your hypothetical algorithm can solve which toposort > can't? Doesn't topsort require that you find a single version that satisfies all dependencies? It's easy to construct things that will work for the way ru

Re: [rust-dev] Deprecating rustpkg

On Fri Jan 31 2014 at 3:33:00 PM, Tony Arcieri wrote: > I am strongly suggesting before you go down this road you figure out: > > 1) *Exactly* what problem you're trying to solve > 2) *Exactly* how you intend to solve it > I'll try to find some time today/weekend to write up a Google Doc explain

Re: [rust-dev] Deprecating rustpkg

I see where Tony is coming from for this one. Just because we *can* doesn't necessarily mean we should. If possible we should definitely prefer to find a common version that both libraries can be happy with. I myself don't have the answers to his questions, though. On Fri, Jan 31, 2014 at 6:24 PM,

Re: [rust-dev] Deprecating rustpkg

On Fri, Jan 31, 2014 at 3:24 PM, Strahinja Markovic wrote: > I honestly can't even say I understand what exactly you mean by > "toposort-style dependency resolution", but I can't help but feel that the > answer to your question is *"Why do we care?".* Implementing an algorithm > that fulfills the

Re: [rust-dev] Deprecating rustpkg

On Fri Jan 31 2014 at 3:03:54 PM, Tony Arcieri wrote: I am 100% clear that, from a technical perspective, Rust has the ability to support multiple different versions of the same library simultaneously. However: 1) Is this a good idea? Of course it's a good idea. There's a need for that today

Re: [rust-dev] Deprecating rustpkg

On Fri, Jan 31, 2014 at 3:07 PM, Daniel Micay wrote: > http://en.opensuse.org/openSUSE:Libzypp_satsolver > Thanks for the link, but upon cursory examination I'm not seeing specifically how this determines whether or not a given set of constraints is: 1) Solvable by a single version of a package

Re: [rust-dev] Deprecating rustpkg

On Fri, Jan 31, 2014 at 3:11 PM, Tony Arcieri wrote: > Can you link me something which explains how this particular problem is > resolved specifically? > Also I would really like to see an example of a problem that can be solved by multiple versions of a package which systems like Maven/Bundler/

Re: [rust-dev] Deprecating rustpkg

On Fri, Jan 31, 2014 at 6:03 PM, Tony Arcieri wrote: > On Fri, Jan 31, 2014 at 2:59 PM, Strahinja Markovic wrote: >> >> This is exactly the system I was referring to. Rust makes it easy to have >> multiple versions of a library linked into a single binary. If the libraries >> you depend on all as

Re: [rust-dev] Deprecating rustpkg

On Fri, Jan 31, 2014 at 2:59 PM, Strahinja Markovic wrote: > This is exactly the system I was referring to. Rust makes it easy to have > multiple versions of a library linked into a single binary. If the > libraries you depend on all ask for the latest (or unspecified) version of > a library, you

Re: [rust-dev] Deprecating rustpkg

On Fri Jan 31 2014 at 2:29:16 PM, Jack Moffitt wrote: > > I am still confused about: > > > > 1) In what situations are you saying there would actually be a workable > > multi-version solution that wouldn't exist in a system like Maven > > 2) How these solutions are calculated > > Every symbol in

Re: [rust-dev] Deprecating rustpkg

On Fri, Jan 31, 2014 at 2:29 PM, Jack Moffitt wrote: > Every symbol in a crate is hashed with its version. You can load two > extern mod's of the same libriary with different versions with no > problems. [...] > This is not what I'm asking. I understand this "works". I am curious specifically a

Re: [rust-dev] Deprecating rustpkg

> I am still confused about: > > 1) In what situations are you saying there would actually be a workable > multi-version solution that wouldn't exist in a system like Maven > 2) How these solutions are calculated Every symbol in a crate is hashed with its version. You can load two extern mod's of

Re: [rust-dev] Deprecating rustpkg

On Fri, Jan 31, 2014 at 1:12 PM, Vladimir Lushnikov < vladi...@slate-project.org> wrote: > If they're incompatible - you're out of luck - the library authors did not > foresee this and you must deal with it yourself. This is for example why > maven supports their 'exclusion' mechanism ( > https://

Re: [rust-dev] Deprecating rustpkg

On Fri, Jan 31, 2014 at 9:05 PM, Tony Arcieri wrote: > On Fri, Jan 31, 2014 at 12:51 PM, Vladimir Lushnikov < > vladi...@slate-project.org> wrote: > >> So for slots distinguish the versions that you are trying to pick between >> - if you package only depends on slot 1, then you pick the highest v

Re: [rust-dev] Deprecating rustpkg

On Fri, Jan 31, 2014 at 12:51 PM, Vladimir Lushnikov < vladi...@slate-project.org> wrote: > So for slots distinguish the versions that you are trying to pick between > - if you package only depends on slot 1, then you pick the highest version > available in slot 1. > What if they're incompatible?

Re: [rust-dev] Deprecating rustpkg

Apologies, I thought I did. Package versions consist of a version number and an optional slot. Constraints are a combination of disjunctive and conjunctive clauses in boolean logic. From http://dev.gentoo.org/~zmedico/portage/doc/pt02.html(which explains what portage does): "Each conjunctive claus

[rust-dev] Deprecating rustpkg

On Friday, January 31, 2014, Vladimir Lushnikov > wrote: > There are some very interesting questions being raised here. > You quoted my question (perhaps unintentionally) but didn't answer it... What algorithm do you use to resolve dependencies in a multi-versioned world? For a world where you'r

Re: [rust-dev] Deprecating rustpkg

I agree, the system is flawed as it relies upon the original developer. But because IMHO we should be considering a build-from-source approach (like python, unlike Java) it is also easy to fix - just create a fork with the changes you want. Certainly that is what we do with quite a few libraries th

Re: [rust-dev] Deprecating rustpkg

There are some very interesting questions being raised here. I think I can add to the discussion: [A] The problem of each version being in its own namespace can be solved by "slots" (at least that's what portage calls them). See http://devmanual.gentoo.org/general-concepts/slotting/ Basically you

Re: [rust-dev] Deprecating rustpkg

On Jan 31, 2014, at 12:23 PM, Vladimir Lushnikov wrote: > There are some very interesting questions being raised here. I think I can > add to the discussion: > > [A] The problem of each version being in its own namespace can be solved by > "slots" (at least that's what portage calls them). Se

Re: [rust-dev] Deprecating rustpkg

On Fri, Jan 31, 2014 at 10:12 AM, Strahinja Markovic wrote: > You depend on the latest version of a lib or on a specific, explicit > version. People who don't care about the old version use the latest, and > people who need the old lib version because they haven't updated use that. > What algorit

Re: [rust-dev] Deprecating rustpkg

On Fri Jan 31 2014 at 10:01:32 AM, Tony Arcieri wrote: > Or can you find a solution where both lib A and lib B are happy with one > particular version of lib C? > You often cannot find one version that satisfies everyone. I've explained the reasons why in my previous email. > At what point can

Re: [rust-dev] Deprecating rustpkg

On Thu, Jan 30, 2014 at 6:37 PM, Val Markovic wrote: > I'll second Armin and Corey here; if lib A and B depend on different > versions of lib C, you *must* still be able to easily build and link them > together as deps of lib D. This is *critical* in large codebases > I would personally say havi

Re: [rust-dev] Deprecating rustpkg

Hi all, > 4) If an incompatible change happens, then it's not fulfilling the same > library API any more, so you stop trying to force square pegs into round > holes, and **just rename the damn thing** ;) ;) According to this logic Rust itself should have been renamed at least nine times already

Re: [rust-dev] Deprecating rustpkg

> > 1) If a minor change or bugfix happens, increment the minor version. > 2) If a major change, which is backwards compatible (i.e., new features) > happens, then increment the major version. > 3) When loading libraries, you can specify a major and a minor version, > with 0 for the minor version i

Re: [rust-dev] Deprecating rustpkg

On 31/01/14 08:05, Gaetan wrote: Le vendredi 31 janvier 2014, Val Markovic > a écrit : .This is a huge problem in large C++ codebases. It is not fun. An example: every version of Xerces-C++ puts its code in a new C++ namespace

Re: [rust-dev] Deprecating rustpkg

Le vendredi 31 janvier 2014, Val Markovic a écrit : > .This is a huge problem in large C++ codebases. It is not fun. An example: > every > version of Xerces-C++ puts its code in a new C++ > namespace, > so code is in xerces_3_0, xerces_3_

Re: [rust-dev] Deprecating rustpkg

It's also the case when you only have binary copies of a given thing, rather than source... On Thu, Jan 30, 2014 at 10:05 PM, Owen Nelson wrote: > I don't believe I'll be able to sleep tonight. > > > On Thu, Jan 30, 2014 at 6:37 PM, Val Markovic wrote: >> >> And now imagine a (frighteningly comm

Re: [rust-dev] Deprecating rustpkg

I don't believe I'll be able to sleep tonight. On Thu, Jan 30, 2014 at 6:37 PM, Val Markovic wrote: > And now imagine a (frighteningly common) nightmare scenario, where the > library version clash is not two steps away from you, but say 8 and 12. So > you link something that depends on something

Re: [rust-dev] Deprecating rustpkg

I'll second Armin and Corey here; if lib A and B depend on different versions of lib C, you *must* still be able to easily build and link them together as deps of lib D. This is *critical* in large codebases where it's not feasible to go into A and B and update which version of C they depend on sin

Re: [rust-dev] Deprecating rustpkg

Hi, On 30/01/2014 23:08, Tony Arcieri wrote: What if the different versions of the library do incompatible things, like: - Talk incompatible versions of a network protocol - Serialize data differently - One contains important security fixes the other does not They are different libraries. It's

Re: [rust-dev] Deprecating rustpkg

On Thu, Jan 30, 2014 at 3:05 PM, Corey Richardson wrote: > I find it both useful and pleasant. I can write a lib that uses > version X of libA, but have an application using version Y of libA be > able to link to me. This isn't a problem in Rust because symbol names > include the version (as wel

Re: [rust-dev] Deprecating rustpkg

On Thu, Jan 30, 2014 at 6:02 PM, Tony Arcieri wrote: > On Thu, Jan 30, 2014 at 2:28 PM, Tim Chevalier > wrote: >> >> ...the design was to treat different versions of the same package as >> separate entities that can coexist. That's why package IDs include optional >> versions. > > > RubyGems does

Re: [rust-dev] Deprecating rustpkg

On Thu, Jan 30, 2014 at 2:28 PM, Tim Chevalier wrote: > ...the design was to treat different versions of the same package as > separate entities that can coexist. That's why package IDs include > optional versions. > RubyGems does this, and I think it was a mistake that has lead to an explosion o

Re: [rust-dev] Deprecating rustpkg

On Thu, Jan 30, 2014 at 2:20 PM, Tony Arcieri wrote: > On Thu, Jan 30, 2014 at 11:26 AM, Tim Chevalier > wrote: >> >> In the interest of documentation (especially for the benefit of >> whatever person or people end up writing the next package manager), >> can you explain what specific architectur

Re: [rust-dev] Deprecating rustpkg

On Thu, Jan 30, 2014 at 11:26 AM, Tim Chevalier wrote: > In the interest of documentation (especially for the benefit of > whatever person or people end up writing the next package manager), > can you explain what specific architectural issues in rustpkg preclude > the addition of (better?) depen

Re: [rust-dev] Deprecating rustpkg

On Wed, Jan 29, 2014 at 1:50 PM, Tony Arcieri wrote: > On Wed, Jan 29, 2014 at 1:13 PM, Jan Niklas Hasse > wrote: >> >> I'm very shocked and also very much against removing it. I've just >> started with Rust a few months ago and actually rustpkg was the thing >> that I liked the most. I know it's

Re: [rust-dev] Deprecating rustpkg

Yeah, neither rustpkg nor cargo before it (which I'd contributed to) solved the interesting problems. Chalk it up to CADT and let's move on. Kevin On Jan 29, 2014 9:50 PM, "Tony Arcieri" wrote: > On Wed, Jan 29, 2014 at 1:13 PM, Jan Niklas Hasse wrote: > >> I'm very shocked and also very much a

Re: [rust-dev] Deprecating rustpkg

On Wed, Jan 29, 2014 at 1:13 PM, Jan Niklas Hasse wrote: > I'm very shocked and also very much against removing it. I've just > started with Rust a few months ago and actually rustpkg was the thing > that I liked the most. I know it's buggy and unfinished, but at least > the idea looked wonderful

Re: [rust-dev] Deprecating rustpkg

On Mon, Jan 27, 2014, at 05:25 PM, Brian Anderson wrote: > Hey again, Rusticians. > > So I think most of us know that rustpkg isn't quite working the way > people expect, and the general consensus seems to be that its flaws > extend pretty deep, to the point where it may just not be exposing the

Re: [rust-dev] Deprecating rustpkg

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

Re: [rust-dev] Deprecating rustpkg

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 rustp

Re: [rust-dev] Deprecating rustpkg

Keeping it around means maintaining it, and it means tempting people to use it even though it's deprecated. My suggestion would be, if you really need rustpkg, then extract it into a separate repo and maintain it there. But get it out of the mozilla/rust tree. -Kevin On Jan 28, 2014, at 11:28

Re: [rust-dev] Deprecating rustpkg

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 w

Re: [rust-dev] Deprecating rustpkg

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 mysel

Re: [rust-dev] Deprecating rustpkg

On 01/28/2014 04:33 AM, Lee Braiden 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

Re: [rust-dev] Deprecating rustpkg

On 01/28/2014 10:33 AM, Lee Braiden wrote: 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 packa

Re: [rust-dev] Deprecating rustpkg

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 sp

Re: [rust-dev] Deprecating rustpkg

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,

Re: [rust-dev] Deprecating rustpkg

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

Re: [rust-dev] Deprecating rustpkg

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

Re: [rust-dev] Deprecating rustpkg

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 coul

  1   2   >