They have a partial ordering wrt a particular repo. Many repos have
straight-line histories, and thus have a total ordering.
So how do I find out the ordering of your x repository here in my
machine, possibly without having x installed. Or your repo cloned?
I'm assuming that a source-based versioning system has a checkout of
the source, just as a binary-based versioning system has a copy of the
binary.
The root cause of this situation is not a broken version system, but
broken API design. If you need 4.1 and clj-apache-http needs 4.0.1
and both can't coexist, then you are hosed.
That's not the problem situation I'm talking about; of course truly
mutual incompatibility can't easily be resolved. I'm talking about
*describing* dependencies.
If my library *requires* 4.0.1, and another library puts 4.1 in its
descriptor (perhaps that's the latest version on the website), then
problems will arise when I combine the two. Without AOT, one will fail
to build. With AOT, one will fail at runtime.
The solution depends on knowledge of the library's requirements: you
have to know which libraries will or won't work with a certain version
(and cascade that through all of their dependencies). It might be
perfectly acceptable to use the other library with 4.0.1. It might
even be acceptable to use both versions simultaneously, or both if you
load them in the right order!
If Lein/etc. allows you to specify "I must have something API-
compatible with 4.0.1", and have that resolved, then great. So far I
haven't seen a way to do that. Leiningen brushes it off with "use
semantic versioning", which isn't much help if your requirements are
more fine-grained (say if the next version is -- strictly speaking --
API compatible, but you need or want to use a different implementation
to reflect new API availability).
I foresee a future with a lot more time spent modifying other people's
project files.
Maybe we need to spend a little time thinking of the appropriate way
to codify workarounds for this kind of thing: imposing corrected
dependencies on upstream libraries; specifying that some library
should be built from source; using predicates to decide on
dependencies; etc.
From what you've written it appears that work has been done on
dependency management systems that make some of these tasks easier
(e.g., Gradle). Unfortunately, this whole adventure with Leiningen was
prompted by a ton of libraries that I use moving to Leiningen, and
removing any way for me to build them without it, so I'm interested in
solutions for Leiningen. If I wanted to spend the time integrating
these libraries with another build system, I'd restore the build.xml
from their history...
Thanks for the discussion.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
