[rust-dev] Deprecating rustpkg
vladimir at slate-project.org
Fri Jan 31 13:12:37 PST 2014
On Fri, Jan 31, 2014 at 9:05 PM, Tony Arcieri <bascule at gmail.com> wrote:
> On Fri, Jan 31, 2014 at 12:51 PM, Vladimir Lushnikov <
> vladimir at 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? In a very handwavey manner, rustpkg claims
> it want to (but does not) support semantic versioning. An unexpected major
> version bump is to be avoided, IMO, and pinning to a specific version is a
> bad solution.
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 (
but also there is no reason you should not be able to manually say to
rustpkg - 'I know that version x.y.z works for both so please give me that
> If you have a package whose libraries depend on incompatible versions of
>> the same library (the definition of incompatible being what was specified
>> in the packages that declare their dependencies) - then you get a
>> resolution error.
> Why even bother to support multiple versions in this case?
> 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 version an
> antipattern. Among other things, pinning to specific versions precludes
> software updates which may be security-critical.
I agree, pinning to a specific version should be avoided (although you have
x.y.z.patch versions sometimes, with you being unable to specify the patch
version as a dependency, which kind of solves the problem) - but I did not
advocate pinning to a particular version.
For example, if I know that I depend on a library of a particular version,
I frequently just go and specify '>= 1.x' as the constraint. Maybe the slot
should be constrained always so that you manually have to bump the version
if a new library release with a new slot is released. Slots in this case
could fill the sematic position of a 'major version'.
By the way, I have not seen how package resolution will handle the case of
a different rust compiler version (especially for binary packages). This is
something Scala addresses for example by guaranteeing binary compatibility
for major compiler versions, and binary packages are typically versioned
with 'slots' that represent the compiler version (though actually they are
just part of the package name if you just use maven and not sbt).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev