2009/3/23 Phil Hagelberg <p...@hagelb.org> > > Bradbev <brad.beveri...@gmail.com> writes: > > > I feel that the next big growth phase for Clojure will be in the user > > community and the code that we can generate. A good package manager > > will help fuel that growth. > > I agree. The more I work with packages that have dependencies the more I > realize that manually managing them will simply not scale. > > > And now I'll cop out & say that I have no idea about how to actually > > implement this sort of thing - I'm hoping somebody else will want to > > do it for me :) > > As Paul mentioned, adding to the classpath at runtime supposedly is > fraught with peril, though I've never got a clear answer whether this > applies to Clojure code or just Java code. I suspect it may be workable > to have shell scripts that set up the classpath rather than calculating > it from within Clojure code. This may be the trickiest part of the > implementation since most languages with package managers have a load > path mechanism that's much more flexible than the JVM's. > > I definitely think being able to read from the Maven repository format > sounds like a good idea, though I haven't had too much interaction with > the tool itself.
Yes. Some other posts in the same thread mention maven. I was once the man who introduced maven in my software company. It was maven1's days. Then came maven2. I didn't really spend time follow maven2, but it seems to be a big thing, but still, they indeed seem to have the repository and dependency management quite right. But I know of people who then turned their back to maven, for several reasons, and embraced Ivy ( http://ant.apache.org/ivy/ ). They don't seem to have looked back since. I don't know Ivy well myself, but it seems to provide what we want here (dependency management), do just that, and do that well. Ah, ant it is also compatible with maven repositories. > > > It would probably be good to just start brainstorming about what > features would be needed for such a tool: > > * Servers need to host jars as well as indices of metadata about jars > that would indicate versions, descriptions, and dependencies between > jars. That's what repositories such as maven2 or Ivy ones do. > > > * The client needs to be able to download jars and their dependent jars > and store them on disk. Multiple versions of a library should be able > to be installed at once. (apt-get doesn't support this natively, and a > lot of unfortunate hacks are needed to work around this.) Packages > should be able to specify which servers each dependency should come > from. Jars should be able to be installed on a system-wide level as > well as in a user's home directory. That's also among the functionalities of the above cited tools. Maybe not exactly as stated by you, but in a manner that has satisfied those java developers willing to correctly manage their dependencies for years. > > > * Code needs to be able to state its dependencies, probably as part of > the ns macro. Flexible version declarations will be necessary. (eg. I > need exactly version 1.8.0 of a library, I need at least version 2.3.1 > of a library, or I need any version in the 0.9 series starting with > 0.9.1 but allowing in bugfix point-releases.) I'm not sure this should be done at the namespace level. It seems too fine grained to me. Of course, a library could consist of just one namespace, but in the general case, I think it would consist of several ones. Just as java libraries generally consist of several packages. Oh, did I just use the word "library" above ? That's a subject I have wanted to talk about for a while. I have read all I could find about the "lib" concept in clojure : docstrings, apge in the clojure.org website. And still, I don't understand why there is this concept of "library", so close to the concept of "namespace" that they are just "theoretically different from each other" to me. There is a stated "one to one" mapping between a "lib" and a "namespace", and very quickly we are talking about namespaces, the functions take symbols that are those of the namespaces, etc. It seems to me that the *current* notion of a "lib", that was certainly meant to be more "abstract" than a namespace, fails to be that. And, finally, I really don't know why the namespace should be made a second class citizen, hidden behind the "lib", as if the "lib" were the "noble part", and the namespace were the (bouuh) "dirty part" (such as distinguishing API from implementation detail). I think the concept of namespace deserves all what's written about the current notion of a clojure "lib". And that the notion of a clojure "lib" deserves more than what it is currently meant to signify: that is, what we're talking about in the current thread: A "lib" could be "the unit of release, made of one or several namespaces, having a (globally unique) name id, a version." The name of the lib would me made unique by following the standard java convention for naming packages (e.g. give the lib the name of its most important namespace, from a user's point of view). For being able to be dependent on either a pure clojure lib, or on classical java lib, we should indeed try to embrace one of the de-facto standard repositories : maven2 or Ivy. I guess that Ivy API may more easily provide hooks for interoperability than maven2 API. The other metadata that could be placed on a lib could then be aligned with the possibility of the standard format: maven2 or Ivy. Or you could start from scratch and invent your own perfect standard, but that would isolate clojure from the rest of the java crowd. And being able to interoperate with the java libraries ecosystem is one of the strengths of clojure one should neglect with care, I think. Wow, thanks if you read past through this long post, What do you think about all this ? Regards, -- Laurent > > > Anything else? I'd love to help out with implementation, whether by > hacking Sauron or some other (hopefully less evil) alternative, but I > think it's important that our efforts be unified. > > -Phil > http://technomancy.us > > > > -- Cordialement, Laurent PETIT --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
