Re: User contributed packages (Cabel, CPAN, etc)
Sounds like OSGi. Any progress on Clojure working with OSGi? On Mar 22, 9:59 pm, Phil Hagelberg p...@hagelb.org wrote: 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. 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. * 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. * 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.) 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. -Philhttp://technomancy.us --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: User contributed packages (Cabel, CPAN, etc)
2009/3/23 Warren warrenthomasw...@yahoo.com Sounds like OSGi. Any progress on Clojure working with OSGi? Hello, For the general OSGi infrastructure, I don't know. For Eclipse in particular, yes: I've succesfully run a proof of concept class from within clojuredev. To be able to do that, I have used the Eclipse buddy feature, more specifically the registered policy which allows a plugin (here the plugin with clojure core) to search classes in the plugins that depend on itself AND also registered themselves specifically as buddies of the clojure plugin. Though, I think it is an eclipse extension to the OSGi platform. There was also a success case reported by Gaetan, but this currently requires (as far as I know) to patch clojure, and since I haven't seen the code yet, I can't tell if there's a chance, by modifying it, to make it an acceptable patch for clojure core. -- Laurent On Mar 22, 9:59 pm, Phil Hagelberg p...@hagelb.org wrote: 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. 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. * 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. * 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.) 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. -Philhttp://technomancy.us --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: User contributed packages (Cabel, CPAN, etc)
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
Re: User contributed packages (Cabel, CPAN, etc)
I had started on something like a package manager called Sauron (one library to rule them all). My idea was to be able to define dependencies with something like: (depends-on :name clojure-json :version 1.2.3) This would look into a ~/.sauron directory and either add a jar or a directory to the classpath. If clojure-json did not exist in ~/.sauron, the it would attempt to download it from a remote repository. The remote repositories would be either GitHub, or a Maven repo, and there would be a way to write a plugin for Sauron to add a new type of repository. I had thought that I would look into if it were possible to somehow plug this into the 'ns macro so that it could be declared with the namespace. Finally, I had thought that transitive dependencies could be handled by having a .sauron file in the root directory of a project so that Sauron would know how to find the dependencies for clojure-json, etc. http://github.com/pjstadig/sauron/tree/master I had thought through all of this, and started on some code, but it's not finalized. I had heard that dynamically adding to the classpath is not foolproof and somewhat dependent on the class loader. I'm not sure if I'm headed in the right direction, or if this is even possible, but it's worked for my limited testing, and I'm open to suggestions and contributions. Paul On Sun, Mar 22, 2009 at 12:57 PM, Bradbev brad.beveri...@gmail.com wrote: Is the clojure-contrib portion of Clojure meant to act as a package system like Cabel, CPAN, etc? I suspect not. Clojure-contrib is more like the standard library that comes with Clojure. I think that going forward, Clojure is going to want to have a large and easily accessible library of packages. I would love to see a strong package system for Clojure that 1) Made it very easy to search for packages download them, along with all the packages they depend upon 2) Made the bar for contributing packages as low as possible so people can contribute easily (Ideally, after you have configured the package manager, uploading a new package should be as easy as 'packman upload mypackage') 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. 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 :) Thanks, Brad --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: User contributed packages (Cabel, CPAN, etc)
I was hoping that we could piggy-back on one of Java's packaging systems, so our programs can depend on Java libraries just as easy as Clojure libraries. And in this regard, the Maven repository system is pretty popular and even supported by build tools other than Maven (such as Ivy, Buildr and Gradle). On Sun, Mar 22, 2009 at 5:57 PM, Bradbev brad.beveri...@gmail.com wrote: Is the clojure-contrib portion of Clojure meant to act as a package system like Cabel, CPAN, etc? I suspect not. Clojure-contrib is more like the standard library that comes with Clojure. I think that going forward, Clojure is going to want to have a large and easily accessible library of packages. I would love to see a strong package system for Clojure that 1) Made it very easy to search for packages download them, along with all the packages they depend upon 2) Made the bar for contributing packages as low as possible so people can contribute easily (Ideally, after you have configured the package manager, uploading a new package should be as easy as 'packman upload mypackage') 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. 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 :) Thanks, Brad -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: User contributed packages (Cabel, CPAN, etc)
On Mar 22, 12:57 pm, Bradbev brad.beveri...@gmail.com wrote: Is the clojure-contrib portion of Clojure meant to act as a package system like Cabel, CPAN, etc? I suspect not. Clojure-contrib is more like the standard library that comes with Clojure. Speaking as a contributor, I don't think it's big enough to qualify as a standard library yet. It's just odds and ends, plus a testing ground for possible new features in core. On Mar 22, 5:46 pm, Christian Vest Hansen karmazi...@gmail.com wrote: I was hoping that we could piggy-back on one of Java's packaging ... the Maven repository system is pretty popular and even supported by build tools other than Maven Maven is a big, complicated beast, but... it's there, it's widely deployed, and it's Java. That makes it a good choice in my book. The less new infrastructure Clojure requires, the better, I believe. -Stuart Sierra --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: User contributed packages (Cabel, CPAN, etc)
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. 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. * 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. * 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.) 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
