puzzler wrote:
> I decided it would be a bad idea to include rhizome
> directly in instaparse's dependencies. Nevertheless, it
> made sense to enable the "visualize" function *provided*
> rhizome was already in the user's dependencies.
I prefer to avoid these kinds of load-time tricks, as they
bre
This thread came up right around the time I was considering adding a
dependency on rhizome to instaparse to make it easy to visualize the parse
trees. Based on the discussion here, I decided it would be a bad idea to
include rhizome directly in instaparse's dependencies. Nevertheless, it
made sen
Using the decomposition I made earlier, I would refine my analysis a bit
further and say:
- the original problem lies mostly within the programming model: it's about
resolving dependencies when reusing and composing deployable units, and how
to avoid complexity and conflicts.
- part of the probl
I must admit that I haven't read every response in this thread but my gut
feeling is that a lot of the "I just need a couple of functions" situations
would be mitigated by making non-core devs feel more welcome to suggesting and
contributing modular contrib ideas. I hate to bring up process beca
On Thu, May 16, 2013 at 8:51 AM, Laurent PETIT wrote:
> How is the advice of each library re-creating for itself little
> utility functions, again and again, going to address the specific
> concern of "made it hard to read code written by anyone else" ?
>
If the functions are in the same file or
Hello,
2013/5/16 Stuart Sierra :
>
> On Wed, May 15, 2013 at 11:35 PM, Michael Fogus wrote:
>>
>> Are Common Lispers actively suffering under this problem?
>
>
> I certainly suffered from it back when I used Common Lisp. Every library was
> written in its own dialect of CL based on a different se
On May 15, 2013, at 8:28 AM, Dave Kincaid wrote:
> One that I encountered last week was Midje. In trying to work through all of
> its dependencies I discovered that Pomegranate is also dependent on Maven,
> but I think I was able to work around that by adding 4 or 5 Maven libraries
> into our
I did not intend to say that libraries should never have any dependencies
at all. (Perhaps "zero" was too strong in my original post.)
I only ask that libraries try to avoid any **unnecessary** dependencies.
Many "utility" libraries fall into this category, especially if you only
depend on them fo
On Wed, May 15, 2013 at 11:35 PM, Michael Fogus wrote:
> Are Common Lispers actively suffering under this problem?
I certainly suffered from it back when I used Common Lisp. Every library
was written in its own dialect of CL based on a different set of these
"utilities." It made it hard to read
Timothy Baldridge writes:
> Neither of these snarky answers solve the problem. I just spent an entire
> week updating modules from version of a library that expected a seq of maps
> to one that expected map of seqs of maps. The very nature of data implies
> a format. If that format changes you h
I think this discussion would greatly benefit from some hammock development
time ;)
The original post was quite precise in its scope, but we quickly
side-stepped into related issues, so it feels like we have lost some focus.
On the other hand I think many of us get the feeling we can't provide s
> take this opportunity to ask everyone to help us avoid the dependency
> mess that Common Lisp has gotten into, where there are over a dozen
> such "convenience" libraries[1].
Are Common Lispers actively suffering under this problem? With the
emergence of QuickLisp, CL dependency problems seem t
One that I encountered last week was Midje. In trying to work through all
of its dependencies I discovered that Pomegranate is also dependent on
Maven, but I think I was able to work around that by adding 4 or 5 Maven
libraries into our repository as dependencies (not ideal, but it looked
like
That seems orthogonal to the problem the loader is trying to solve.
--
--
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 w
2013/5/15 Dave Kincaid :
> As long as we remember that not everyone is using Leiningen and/or Maven.
> There are other build and dependency systems out there, so any change to
> dependency management tooling will have to cover all of them.
>
> There are already popular libraries that don't work out
As long as we remember that not everyone is using Leiningen and/or Maven.
There are other build and dependency systems out there, so any change to
dependency management tooling will have to cover all of them.
There are already popular libraries that don't work outside of Leiningen,
but that's
At the risk of making a slight strawman here, I agree this issue has the
potential to drag on Clojure adoption - but in the opposite way to what you
describe.
At the root of it, is the Clojure ecosystem a "dependencies are bad"
system, or a "dependencies are good" system?
The former encourages
It may be pragmatic currently but *manually* copying code is a bad
solution. Not depending on libraries is not a good solution either. The
premise that there are only 3 levels of composition - clojure -> library ->
application - I think is wrong, even if it works and is useful in some
cases.
D
This thread seems to have gotten way off track and I think that Stuart made
a very important point in the original post that's getting lost. It would
help all of us out if library authors stopped making their libraries
dependent on 10+ other libraries. This issue does have the potential to
real
Stuart Sierra writes:
> On Tue, May 14, 2013 at 3:25 AM, Phil Hagelberg wrote:
>
>> It's really not difficult to do if you limit yourself to Clojure since
>> Clojure namespaces are first-class and easy to manipulate at
>> run-time. We implemneted a prototype of this in under two hours at a
>> Sea
Neither of these snarky answers solve the problem. I just spent an entire
week updating modules from version of a library that expected a seq of maps
to one that expected map of seqs of maps. The very nature of data implies
a format. If that format changes you have a compatibility issue no fancy
n
Or a reason to integrate via data, not api or type.
On Monday, May 13, 2013 10:54:26 PM UTC+2, Phil Hagelberg wrote:
>
>
> Stuart Sierra writes:
> > That's cool, and it will work for the simple case of libraries A and B
> > depending on different versions of C.
> >
> > But it still breaks down
Stuart Sierra writes:
> That's cool, and it will work for the simple case of libraries A and B
> depending on different versions of C.
>
> But it still breaks down in more complex cases: e.g. if I want to share
> data between A and B using a protocol or type defined in C, and there are 2
> incompa
On Tue, May 14, 2013 at 3:25 AM, Phil Hagelberg wrote:
> It's really not difficult to do if you limit yourself to Clojure since
> Clojure namespaces are first-class and easy to manipulate at
> run-time. We implemneted a prototype of this in under two hours at a
> Seajure meeting a while back:
>
>
I'm guilty of this... But I really don't know what to do I still find
myself thinking... Hmmm this library provides about 50% of what I want... This
library has 2 functions that I like And I don't like the way something is
implemented here... If only i can combine this, this, and this...
Angel Java Lopez writes:
> I guess it could be difficult to implement such feature in Java/Clojure
It's really not difficult to do if you limit yourself to Clojure since
Clojure namespaces are first-class and easy to manipulate at
run-time. We implemneted a prototype of this in under two hours a
On Mon, May 13, 2013 at 1:42 AM, Meikel Brandmeyer (kotarak)
wrote:
> Hi,
>
> Am Montag, 13. Mai 2013 10:35:14 UTC+2 schrieb Stuart Sierra:
>>
>>
>>
>> I believe "lightweight dependency loading system" is an oxymoron. Either
>> you A) design a new module format and try to get everyone to follow it
Are dependencies the potential problem, or are "utility belt" dependencies
the issue here?
If its the latter, then should we be trying to break down the utility belt
into groups of related functionality, which can be stable and focused.
Promoting zero-dependency libraries just means re-inventin
Hi,
Am Montag, 13. Mai 2013 10:35:14 UTC+2 schrieb Stuart Sierra:
>
>
>
> I believe "lightweight dependency loading system" is an oxymoron. Either
> you A) design a new module format and try to get everyone to follow it
> (OSGI) or B) build an ad-hoc solution that tries to guess at the right
>
On Mon, May 13, 2013 at 12:55 PM, Mikera wrote:
> Maybe we could try to develop towards some kind of lightweight dependency
> loading system that avoids this problem?
I believe "lightweight dependency loading system" is an oxymoron. Either
you A) design a new module format and try to get everyo
Yes, by all means please just copy-n-paste out of
https://github.com/runa-dev/kits if it simplifies your dependency tree.
On Sun, May 12, 2013 at 8:53 PM, Dave Kincaid wrote:
> Thanks for this, Stuart. I hope it's not too late. As one who has spent
> the last couple weeks spinning up a new projec
Thanks for this, Stuart. I hope it's not too late. As one who has spent the
last couple weeks spinning up a new project that uses its own local Ivy
repository I've been feeling this pain first hand. The number of
dependencies I have had to add just for a few Clojure libraries has been
quite pai
On Monday, 13 May 2013 09:20:19 UTC+8, Stuart Sierra wrote:
> Isolated dependency loading is not possible in the JVM without complex
> ClassLoader-based schemes like OSGI, which come with their own set of
> problems.
>
> -S
>
>
Hi Stuart,
That's true for compiled Java classes on the classpath,
Isolated dependency loading is not possible in the JVM without complex
ClassLoader-based schemes like OSGI, which come with their own set of
problems.
-S
On Mon, May 13, 2013 at 9:45 AM, Angel Java Lopez wrote:
> Node.js + NPM (its package manager) has a nice version management.
>
> If your mo
Only a lateral quick comment:
Node.js + NPM (its package manager) has a nice version management.
If your module A needs D version 0.1, and module B needs D version 0.2, no
problem. Both versions are added, and A loads version 0.1, meanwhile B
loads version 0.2. The trick is the search path for mo
35 matches
Mail list logo
