I like this idea too, because if you end up wanting to port this package
manager to CLR, Parrot, or JS, you're less tied down to the package formats
of specific platforms.
Heck, even if Clojure was ported to Ruby (not that there'd be any point to
do that), you could wrap the Gems framework.
On Sa
On Aug 7, 10:17 am, Lauri Pesonen wrote:
> Surely we can do better with s-expressions:
>
> (:repository "third-party" [(:package "Compojure" "/compojure.xml")])
Not very forward compatible, though.
Perhaps we should sidestep the whole question about the format of
package metadata. At some point
On Aug 7, 1:51 pm, Sean Devlin wrote:
> .car +1 (jar pun)
I'll go against the crowd and say I don't like this name. It seems
confusing to have a "car" symbol in your source code that has an
entirely different purpose to its traditional binding.
- James
--~--~-~--~~~-
I like the name Clojure Archive.
On another note, I always wondered why xml was such a requirement for
Java dependency management. Couldn't we design some sort of url
schema, that you could just pass to a package importer in the
program. First time you run, it could fetch the packages or
automa
+1 on ".car" here too. Plus, I imagine the icon to be a 1950's-era
muscle car; a nod to Lisp's age.
On Fri, Aug 7, 2009 at 8:13 AM, Justin Johnson wrote:
>> car: "Clojure Archive" (half-assed pun on Lisp's car, plus you can
>> imagine the icon!)
>
> +1
>
> >
>
--
Chris Wilson
--~--~---
>
> car: "Clojure Archive" (half-assed pun on Lisp's car, plus you can imagine
> the icon!)
>
+1
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegro
.car +1 (jar pun)
On Aug 7, 5:45 am, Howard Lewis Ship wrote:
> Ruby and Gem is such great terminology, can we come up with something
> half as cool?
>
> Want something short (3 - 4 letters) suitable as a file extension perhaps.
>
> Brainstorming some ideas:
>
> cap: "Clojure Archive Package"
>
On Fri, Aug 7, 2009 at 11:07 AM, Howard Lewis Ship wrote:
>
> Or really work this into core and add :packages to the (ns) macro.
+1
I have been thinking about this recently anyway. Java is too rigid to
work something like this into it's syntax, but Clojure could do it.
The benefits that I see co
On 07/08/2009, at 7:15 PM, Howard Lewis Ship wrote:
>
> Ruby and Gem is such great terminology, can we come up with something
> half as cool?
Closure and Resolution, are a pair of parallel hononymic puns.
Or Clojure/Seal - you close the package and seal it.
Antony Blakey
-
CTO, Li
Hi,
On Aug 7, 11:45 am, Howard Lewis Ship wrote:
> car: "Clojure Archive" (half-assed pun on Lisp's car, plus you can
> imagine the icon!)
The other half of the pun's ass is on Java's jar. ;)
.cljp: clojure package
.clja: clojure archive
Playing with Clojure's source extension .clj.
Sincer
Ruby and Gem is such great terminology, can we come up with something
half as cool?
Want something short (3 - 4 letters) suitable as a file extension perhaps.
Brainstorming some ideas:
cap: "Clojure Archive Package"
cpa: "Clojure Package Archive"
ca: "Clojure Archive"
car: "Clojure Archive" (h
2009/8/6 James Reeves :
>
> On Aug 6, 8:31 pm, Howard Lewis Ship wrote:
>> I'm cringing at the sight of XML here.
>
> XML is frequently overused, but it is a good format for representing
> dense, structured data. For example:
>
>
>
>
>
> Compared to:
>
> {:type :repository
> :name "third-par
Hello,
Not a great contribution to the debate, but just a word on the terminology:
reusing package which already has a strong meaning in java may not be a good
idea, I think.
I think lib or library could be interesting, but it has also been attributed
a meaning more similar to "ns description" in
Or really work this into core and add :packages to the (ns) macro.
On Thu, Aug 6, 2009 at 2:30 PM, James Reeves wrote:
>
> On Aug 6, 10:16 pm, James Reeves wrote:
>> (package/get "compojure" "0.2")
>> (package/get "clojure-contrib" [:>= "1.0-alpha3"])
>>
>> (ns example
>> (:use clojure.contrib
On Aug 6, 10:16 pm, James Reeves wrote:
> (package/get "compojure" "0.2")
> (package/get "clojure-contrib" [:>= "1.0-alpha3"])
>
> (ns example
> (:use clojure.contrib.json.read)
> (:use compojure.html))
I had another thought once after I posted. Perhaps the best of both
syntax ideas could be
On Aug 6, 8:31 pm, Howard Lewis Ship wrote:
> I'm cringing at the sight of XML here.
XML is frequently overused, but it is a good format for representing
dense, structured data. For example:
Compared to:
{:type :repository
:name "third-party"
:content [{ :type :package
:na
I'm cringing at the sight of XML here.
(I almost through this post away when I read down and saw the work on
Corkscrew but I thought some of my ideas might still be valid).
What I'd like to see is something that execute *inside* Clojure,
adding necessary libraries the classpath in some way:
I w
Lauri Pesonen writes:
> Drawing a parallel between Ruby and Clojure, a Clod package could
> expect jars to be available on the platform at package install time.
> It would be up to the user to install those jars before trying to
> install a Clod package. The user is free to install the jar eithe
On Thu, Aug 6, 2009 at 7:07 PM, Antony Blakey wrote:
> This is the first I've heard of this project, but what about the 255
> page user guide available from:
> http://mirror.cc.vt.edu/pub/eclipse/tools/buckminster/doc/BuckyBook.pdf
> ?
Ah, nice one. Hasn't been there last time I checked, thanks
On 06/08/2009, at 8:58 PM, Daniel wrote:
> Have a look at Buckminster: http://www.eclipse.org/buckminster/
> Not sure if it's going to work for non-JVM approaches (you'll probably
> have to code up a plugin of some sort), but it's a meta package
> manager, and can do more than just dependency re
On Thu, Aug 6, 2009 at 4:12 PM, Lauri Pesonen wrote:
> 2009/8/5 Meikel Brandmeyer :
>> Well, this is independent of whether you have a C or Java
>> library. You can install each C library in its own directory
>> and tell the linker to look there. Then you have basically
>> a .jar like setup: If yo
Hi Meikel,
2009/8/5 Meikel Brandmeyer :
>
> Well, this is independent of whether you have a C or Java
> library. You can install each C library in its own directory
> and tell the linker to look there. Then you have basically
> a .jar like setup: If you don't tell the linker the right directory
>
> I'm also wondering whether or not I could construct a package
manager
> that operates from within the REPL. Hmm.
>
Well, if it's written in Clojure you get this one for free right?
BECAUSE THAT WOULD BE AWESOME!
--~--~-~--~~~---~--~~
You received this messag
On Aug 4, 2:44 pm, Sean Devlin wrote:
> James,
> Just go for it. You've certainly proved you can design a library.
> Deliver something that works for you, and tell us if you think it's
> ready. If it's better than other stuff (which I suspect it will be),
> the community will start using it. I
On 5 Aug., 12:07, Meikel Brandmeyer wrote:
>
> Any CLR experts around? How does the packaging work
> there?
Well, there's NMaven:
http://nmaven.codeplex.com/Wiki/View.aspx?title=Getting%20Started
- not sure, though, how popular this is.
The CLR has a built-in versioning concept, which may have
Hi,
On Aug 5, 10:32 am, Lauri Pesonen wrote:
> John Newman brought up a good point as well concerning support for
> other possible clojure platforms like JS, CLR, and Parrot: if we
> support Java library packaging than shouldn't we also support
> packaging on other platforms?
The history book
2009/8/4 Meikel Brandmeyer :
>
> I think, "clojure context" is underestimating things. The high
> integration
> of external Java libraries makes it necessary that such dependencies
> can be handled in the same way.
Agreed. I was actually going to write that whatever approach is chosen
it must be
James Reeves writes:
> On Aug 4, 12:51 pm, Krešimir Šojat wrote:
>> In your project you would create standard ivy.xml and ivysettings.xml
>> files as described on Ivy site. Download Ivy (and Ant jars if you will
>> create or use Packagers). After that you can retrieve your
>> dependencies from
Meikel said,
>
> I think, "clojure context" is underestimating things. The high
> integration
> of external Java libraries makes it necessary that such dependencies
> can be handled in the same way.
>
>
On the other hand, will this package system be able to stradle and
accommodate future platforms
Hi,
On Aug 4, 3:38 pm, Lauri Pesonen wrote:
> (Note: I've been writing Ant macros for the past few weeks and
> I'm starting to develop a very serious case of XML allergy.)
You might want to take a look at Gradle[1]. It exchanges XML for
Groovy,
which might be an advantage or not. It uses Ivy u
James,
Just go for it. You've certainly proved you can design a library.
Deliver something that works for you, and tell us if you think it's
ready. If it's better than other stuff (which I suspect it will be),
the community will start using it. If not, back to the drawing board.
Sean
On Aug 4
2009/8/4 James Reeves :
>
> On Aug 4, 12:51 pm, Krešimir Šojat wrote:
>> In your project you would create standard ivy.xml and ivysettings.xml
>> files as described on Ivy site. Download Ivy (and Ant jars if you will
>> create or use Packagers). After that you can retrieve your
>> dependencies fr
On Aug 4, 12:51 pm, Krešimir Šojat wrote:
> In your project you would create standard ivy.xml and ivysettings.xml
> files as described on Ivy site. Download Ivy (and Ant jars if you will
> create or use Packagers). After that you can retrieve your
> dependencies from command line
As Piyush menti
On 4 kol, 13:21, James Reeves wrote:
> Could you give me an example of how you'd use Ivy in a standalone
> capacity? I was unable to find an example of Ivy being used in the
> same way one would use Rubygems or Apt.
In your project you would create standard ivy.xml and ivysettings.xml
files as
Hi to myself,
On Aug 4, 1:45 pm, Meikel Brandmeyer wrote:
> You can have separate servers for ivy.xmls and artifacts. However the
> problem is that this is configured on a per repository basis. So one
> can't
> have to two ivy.xmls in the same repository with different artifact
> patterns.
> At
Hi,
On Aug 4, 1:21 pm, James Reeves wrote:
> Could you give me an example of how you'd use Ivy in a standalone
> capacity? I was unable to find an example of Ivy being used in the
> same way one would use Rubygems or Apt.
You can do "java -jar ivy.jar --help" to see the options you have,
when
Coming from Ruby land and having used other languages before, I feel
rubygems is quiet a good solution to this problem. Having something like
this in Clojure would be terrific for a person like me who is just starting
up.
>
> > $ clod install foo
> > => installing... done.
> > $ clj
> > user=> (us
On Aug 4, 10:57 am, Krešimir Šojat wrote:
> Ivy can be used as set of Ant tasks, stand-alone command line tool or
> as a library. If used as a library there is nothing stopping you to
> resolve your dependencies at runtime.
Could you give me an example of how you'd use Ivy in a standalone
capaci
> Please correct me if I'm wrong, but both Maven and Ivy appear to be
> designed to resolve dependencies during build time.
Ivy can be used as set of Ant tasks, stand-alone command line tool or
as a library. If used as a library there is nothing stopping you to
resolve your dependencies at runti
On Aug 4, 5:40 am, Phil Hagelberg wrote:
> Maven actually supports dependency resolution. While I don't like Maven
> much for most things, its dependency resolution mechanism and repository
> format is quite good.
Regarding Maven and Ivy, their dependency resolution appears to be
somewhat differ
James Reeves writes:
> I've been sketching out a design for a package manager for Clojure,
> similar to Rubygems. To the best of my knowledge, there's no real
> equivalent to this in Java-land.
>
> I'm looking for suggestions, criticisms, or for someone to tell me
> that Java already has a packa
Hi,
There is Apache Ivy (http://ant.apache.org/ivy/) with it's Packager
resolver that does exactly that (it has almost the same syntax as your
proposal).
For a repository using Apache Ivy + Package take a look at Ivy RoundUp
(http://code.google.com/p/ivyroundup/), good thing about there desing
i
Hi folks,
I've been sketching out a design for a package manager for Clojure,
similar to Rubygems. To the best of my knowledge, there's no real
equivalent to this in Java-land.
I'm looking for suggestions, criticisms, or for someone to tell me
that Java already has a package manager that's bette
43 matches
Mail list logo
