Re: Handling dependency conflicts

[arthur]

Daniel,

 I'll check out OSGi (you might be right about the cure being worse). I 
think Java 9 modules were originally supposed to include versioning as 
well, but currently "The State of the Module System" says "A module’s 
declaration does not include a version string, nor constraints upon the 
version strings of the modules upon which it depends. This is intentional: 
It is not a goal 
 of 
the module system to solve the version-selection problem, which is best 
left to build tools and container applications".

On Thursday, March 16, 2017 at 4:29:47 PM UTC-4, Daniel Compton wrote:
>
> One option to help with this is OSGi which does have support in Clojure. 
> https://github.com/talios/clojure.osgi
>
> As Stuart alluded to in his message, the cure to dependency conflicts 
> (OSGi) may be worse than the disease. I’d guess that the venn diagram of 
> people using both Clojure and OSGi is pretty thin. There is also 
> Jigsaw/JPMS in the upcoming Java 9 which is another take on modularity: 
> https://www.infoq.com/articles/java9-osgi-future-modularity.
>
> On Fri, Mar 17, 2017 at 5:20 AM  
> wrote:
>
>> Howard, thanks for posting that library. I've passed on the info to some 
>> of the other developers at work. That kind of tool is highly valuable, I'll 
>> likely start using it soon.
>>
>> Gary, the MrAnderson approach sounds similar to shading; I'll take a look 
>> today.
>>
>> Stuart, the most common approach boils down to trust and hope, and I 
>> don't think it's good enough. As projects grow larger the likelihood of 
>> running into incompatibilities also grows, regardless of community 
>> etiquette. Thank you for suggesting :pendantic.
>>
>>
>> On Tuesday, March 14, 2017 at 4:49:50 PM UTC-4, Howard M. Lewis Ship 
>> wrote:
>>
>>> We have some very, very complex projects that bring in boat-loads of 
>>> dependencies, some of which will have version conflicts, if left 
>>> unchecked.  I've created a Leiningen plugin, vizdeps, to make it easier to 
>>> see the artifact tree, identify and repair conflicts, and determine why any 
>>> particular artifacts are in the build.
>>>
>>> https://github.com/walmartlabs/vizdeps
>>>
>> On Mon, Mar 13, 2017 at 1:45 PM, Stuart Sierra  
>>> wrote:
>>>
>> This is a well-known problem in the JVM world, not just Clojure.

 The most common approach is: Always use the latest versions, and don't 
 break backwards-compatibility.

 Most open-source Java and Clojure libraries are careful about not 
 breaking backwards-compatibility. So in general, you're safe choosing the 
 latest version of any library.

 Leiningen has the `:pedantic` option which can be set to warn or fail 
 when there are possible dependency conflicts.

 Neither Clojure nor the JVM has explicit support for linking to 
 specific versions of a library. Work-arounds exist, but they often 
 increase 
 overall complexity and lead to conflicts which are harder to debug.

 –S


 On Monday, March 13, 2017 at 4:13:19 PM UTC-4, arthur wrote:
>
> Hello All,
>
>
>  I have a general inquiry regarding conflicting dependencies in 
> Clojure projects and how they affect applications at runtime. I believe 
> this is a common problem faced by many languages in this day and age 
> where 
> we try not to reinvent the wheel by depending on the work of others. 
> Basically: my application depends on libraries *A*, *B*, *C*, and *D*. 
> Libraries *B*, *C*, *D* *also* depend on library *A*, but all of us 
> depend on *different versions* of library *A.* Leiningen thankfully 
> warns us in many of these situations by suggesting exclusions. However, 
> how 
> can I possibly know that something hasn't broken? Stringent testing can 
> give a certain degree of confidence that things are still working, but it 
> would seem to me that to ensure correctness, we should include *all* 
> versions 
> of the dependencies and have the functions link to their respective 
> *versioned* identites. Does anyone have advice on how they solve 
> these kinds of problems on their codebases in the wild? Thankfully 
> nothing 
> has broken yet (to my knowledge), but it seems we have very few 
> assurances 
> here and the best we can do is *hope* nothing is broken. Any advice 
> is much appreciated.
>
> Thanks,
>
> Arthur
>
 -- 
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.

>>> To post to this group, send email to clo...@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+u...@googlegroups.com

>>>
 For more options, visit 

Re: Handling dependency conflicts

[Daniel Compton]

One option to help with this is OSGi which does have support in Clojure.
https://github.com/talios/clojure.osgi

As Stuart alluded to in his message, the cure to dependency conflicts
(OSGi) may be worse than the disease. I’d guess that the venn diagram of
people using both Clojure and OSGi is pretty thin. There is also
Jigsaw/JPMS in the upcoming Java 9 which is another take on modularity:
https://www.infoq.com/articles/java9-osgi-future-modularity.

On Fri, Mar 17, 2017 at 5:20 AM  wrote:

> Howard, thanks for posting that library. I've passed on the info to some
> of the other developers at work. That kind of tool is highly valuable, I'll
> likely start using it soon.
>
> Gary, the MrAnderson approach sounds similar to shading; I'll take a look
> today.
>
> Stuart, the most common approach boils down to trust and hope, and I don't
> think it's good enough. As projects grow larger the likelihood of running
> into incompatibilities also grows, regardless of community etiquette. Thank
> you for suggesting :pendantic.
>
>
> On Tuesday, March 14, 2017 at 4:49:50 PM UTC-4, Howard M. Lewis Ship wrote:
>
> We have some very, very complex projects that bring in boat-loads of
> dependencies, some of which will have version conflicts, if left
> unchecked.  I've created a Leiningen plugin, vizdeps, to make it easier to
> see the artifact tree, identify and repair conflicts, and determine why any
> particular artifacts are in the build.
>
> https://github.com/walmartlabs/vizdeps
>
> On Mon, Mar 13, 2017 at 1:45 PM, Stuart Sierra 
> wrote:
>
> This is a well-known problem in the JVM world, not just Clojure.
>
> The most common approach is: Always use the latest versions, and don't
> break backwards-compatibility.
>
> Most open-source Java and Clojure libraries are careful about not breaking
> backwards-compatibility. So in general, you're safe choosing the latest
> version of any library.
>
> Leiningen has the `:pedantic` option which can be set to warn or fail when
> there are possible dependency conflicts.
>
> Neither Clojure nor the JVM has explicit support for linking to specific
> versions of a library. Work-arounds exist, but they often increase overall
> complexity and lead to conflicts which are harder to debug.
>
> –S
>
>
> On Monday, March 13, 2017 at 4:13:19 PM UTC-4, arthur wrote:
>
> Hello All,
>
>
>  I have a general inquiry regarding conflicting dependencies in
> Clojure projects and how they affect applications at runtime. I believe
> this is a common problem faced by many languages in this day and age where
> we try not to reinvent the wheel by depending on the work of others.
> Basically: my application depends on libraries *A*, *B*, *C*, and *D*.
> Libraries *B*, *C*, *D* *also* depend on library *A*, but all of us
> depend on *different versions* of library *A.* Leiningen thankfully warns
> us in many of these situations by suggesting exclusions. However, how can I
> possibly know that something hasn't broken? Stringent testing can give a
> certain degree of confidence that things are still working, but it would
> seem to me that to ensure correctness, we should include *all* versions
> of the dependencies and have the functions link to their respective
> *versioned* identites. Does anyone have advice on how they solve these
> kinds of problems on their codebases in the wild? Thankfully nothing has
> broken yet (to my knowledge), but it seems we have very few assurances here
> and the best we can do is *hope* nothing is broken. Any advice is much
> appreciated.
>
> Thanks,
>
> Arthur
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
>
> To post to this group, send email to clo...@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+u...@googlegroups.com
>
>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+u...@googlegroups.com.
>
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Howard M. Lewis Ship
>
> Senior Mobile Developer at Walmart Labs
>
> Creator of Apache Tapestry
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>
> --
> 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
> ---
> You received this message because you are subscribed to 

Re: Handling dependency conflicts

[arthur]

Howard, thanks for posting that library. I've passed on the info to some of 
the other developers at work. That kind of tool is highly valuable, I'll 
likely start using it soon.

Gary, the MrAnderson approach sounds similar to shading; I'll take a look 
today.

Stuart, the most common approach boils down to trust and hope, and I don't 
think it's good enough. As projects grow larger the likelihood of running 
into incompatibilities also grows, regardless of community etiquette. Thank 
you for suggesting :pendantic.


On Tuesday, March 14, 2017 at 4:49:50 PM UTC-4, Howard M. Lewis Ship wrote:
>
> We have some very, very complex projects that bring in boat-loads of 
> dependencies, some of which will have version conflicts, if left 
> unchecked.  I've created a Leiningen plugin, vizdeps, to make it easier to 
> see the artifact tree, identify and repair conflicts, and determine why any 
> particular artifacts are in the build.
>
> https://github.com/walmartlabs/vizdeps
>
> On Mon, Mar 13, 2017 at 1:45 PM, Stuart Sierra  > wrote:
>
>> This is a well-known problem in the JVM world, not just Clojure.
>>
>> The most common approach is: Always use the latest versions, and don't 
>> break backwards-compatibility.
>>
>> Most open-source Java and Clojure libraries are careful about not 
>> breaking backwards-compatibility. So in general, you're safe choosing the 
>> latest version of any library.
>>
>> Leiningen has the `:pedantic` option which can be set to warn or fail 
>> when there are possible dependency conflicts.
>>
>> Neither Clojure nor the JVM has explicit support for linking to specific 
>> versions of a library. Work-arounds exist, but they often increase overall 
>> complexity and lead to conflicts which are harder to debug.
>>
>> –S
>>
>>
>> On Monday, March 13, 2017 at 4:13:19 PM UTC-4, arthur wrote:
>>>
>>> Hello All,
>>>
>>>
>>>  I have a general inquiry regarding conflicting dependencies in 
>>> Clojure projects and how they affect applications at runtime. I believe 
>>> this is a common problem faced by many languages in this day and age where 
>>> we try not to reinvent the wheel by depending on the work of others. 
>>> Basically: my application depends on libraries *A*, *B*, *C*, and *D*. 
>>> Libraries *B*, *C*, *D* *also* depend on library *A*, but all of us 
>>> depend on *different versions* of library *A.* Leiningen thankfully 
>>> warns us in many of these situations by suggesting exclusions. However, how 
>>> can I possibly know that something hasn't broken? Stringent testing can 
>>> give a certain degree of confidence that things are still working, but it 
>>> would seem to me that to ensure correctness, we should include *all* 
>>> versions 
>>> of the dependencies and have the functions link to their respective 
>>> *versioned* identites. Does anyone have advice on how they solve these 
>>> kinds of problems on their codebases in the wild? Thankfully nothing has 
>>> broken yet (to my knowledge), but it seems we have very few assurances here 
>>> and the best we can do is *hope* nothing is broken. Any advice is much 
>>> appreciated.
>>>
>>> Thanks,
>>>
>>> Arthur
>>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Howard M. Lewis Ship
>
> Senior Mobile Developer at Walmart Labs
>
> Creator of Apache Tapestry
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Handling dependency conflicts

[Howard Lewis Ship]

We have some very, very complex projects that bring in boat-loads of
dependencies, some of which will have version conflicts, if left
unchecked.  I've created a Leiningen plugin, vizdeps, to make it easier to
see the artifact tree, identify and repair conflicts, and determine why any
particular artifacts are in the build.

https://github.com/walmartlabs/vizdeps

On Mon, Mar 13, 2017 at 1:45 PM, Stuart Sierra 
wrote:

> This is a well-known problem in the JVM world, not just Clojure.
>
> The most common approach is: Always use the latest versions, and don't
> break backwards-compatibility.
>
> Most open-source Java and Clojure libraries are careful about not breaking
> backwards-compatibility. So in general, you're safe choosing the latest
> version of any library.
>
> Leiningen has the `:pedantic` option which can be set to warn or fail when
> there are possible dependency conflicts.
>
> Neither Clojure nor the JVM has explicit support for linking to specific
> versions of a library. Work-arounds exist, but they often increase overall
> complexity and lead to conflicts which are harder to debug.
>
> –S
>
>
> On Monday, March 13, 2017 at 4:13:19 PM UTC-4, arthur wrote:
>>
>> Hello All,
>>
>>
>>  I have a general inquiry regarding conflicting dependencies in
>> Clojure projects and how they affect applications at runtime. I believe
>> this is a common problem faced by many languages in this day and age where
>> we try not to reinvent the wheel by depending on the work of others.
>> Basically: my application depends on libraries *A*, *B*, *C*, and *D*.
>> Libraries *B*, *C*, *D* *also* depend on library *A*, but all of us
>> depend on *different versions* of library *A.* Leiningen thankfully
>> warns us in many of these situations by suggesting exclusions. However, how
>> can I possibly know that something hasn't broken? Stringent testing can
>> give a certain degree of confidence that things are still working, but it
>> would seem to me that to ensure correctness, we should include *all* versions
>> of the dependencies and have the functions link to their respective
>> *versioned* identites. Does anyone have advice on how they solve these
>> kinds of problems on their codebases in the wild? Thankfully nothing has
>> broken yet (to my knowledge), but it seems we have very few assurances here
>> and the best we can do is *hope* nothing is broken. Any advice is much
>> appreciated.
>>
>> Thanks,
>>
>> Arthur
>>
> --
> 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
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Howard M. Lewis Ship

Senior Mobile Developer at Walmart Labs

Creator of Apache Tapestry

(971) 678-5210
http://howardlewisship.com
@hlship

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Handling dependency conflicts

[Stuart Sierra]

This is a well-known problem in the JVM world, not just Clojure.

The most common approach is: Always use the latest versions, and don't 
break backwards-compatibility.

Most open-source Java and Clojure libraries are careful about not breaking 
backwards-compatibility. So in general, you're safe choosing the latest 
version of any library.

Leiningen has the `:pedantic` option which can be set to warn or fail when 
there are possible dependency conflicts.

Neither Clojure nor the JVM has explicit support for linking to specific 
versions of a library. Work-arounds exist, but they often increase overall 
complexity and lead to conflicts which are harder to debug.

–S


On Monday, March 13, 2017 at 4:13:19 PM UTC-4, arthur wrote:
>
> Hello All,
>
>
>  I have a general inquiry regarding conflicting dependencies in 
> Clojure projects and how they affect applications at runtime. I believe 
> this is a common problem faced by many languages in this day and age where 
> we try not to reinvent the wheel by depending on the work of others. 
> Basically: my application depends on libraries *A*, *B*, *C*, and *D*. 
> Libraries *B*, *C*, *D* *also* depend on library *A*, but all of us 
> depend on *different versions* of library *A.* Leiningen thankfully warns 
> us in many of these situations by suggesting exclusions. However, how can I 
> possibly know that something hasn't broken? Stringent testing can give a 
> certain degree of confidence that things are still working, but it would 
> seem to me that to ensure correctness, we should include *all* versions 
> of the dependencies and have the functions link to their respective 
> *versioned* identites. Does anyone have advice on how they solve these 
> kinds of problems on their codebases in the wild? Thankfully nothing has 
> broken yet (to my knowledge), but it seems we have very few assurances here 
> and the best we can do is *hope* nothing is broken. Any advice is much 
> appreciated.
>
> Thanks,
>
> Arthur
>

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Handling dependency conflicts

[Gary Trakhman]

MrAnderson is one possible answer to the question, it's used in CIDER:
https://github.com/benedekfazekas/mranderson

On Mon, Mar 13, 2017 at 4:13 PM  wrote:

> Hello All,
>
>
>  I have a general inquiry regarding conflicting dependencies in
> Clojure projects and how they affect applications at runtime. I believe
> this is a common problem faced by many languages in this day and age where
> we try not to reinvent the wheel by depending on the work of others.
> Basically: my application depends on libraries *A*, *B*, *C*, and *D*.
> Libraries *B*, *C*, *D* *also* depend on library *A*, but all of us
> depend on *different versions* of library *A.* Leiningen thankfully warns
> us in many of these situations by suggesting exclusions. However, how can I
> possibly know that something hasn't broken? Stringent testing can give a
> certain degree of confidence that things are still working, but it would
> seem to me that to ensure correctness, we should include *all* versions
> of the dependencies and have the functions link to their respective
> *versioned* identites. Does anyone have advice on how they solve these
> kinds of problems on their codebases in the wild? Thankfully nothing has
> broken yet (to my knowledge), but it seems we have very few assurances here
> and the best we can do is *hope* nothing is broken. Any advice is much
> appreciated.
>
> Thanks,
>
> Arthur
>
> --
> 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
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Handling dependency conflicts

[arthur]

Hello All,


 I have a general inquiry regarding conflicting dependencies in Clojure 
projects and how they affect applications at runtime. I believe this is a 
common problem faced by many languages in this day and age where we try not 
to reinvent the wheel by depending on the work of others. Basically: my 
application depends on libraries *A*, *B*, *C*, and *D*. Libraries *B*, *C*
, *D* *also* depend on library *A*, but all of us depend on *different 
versions* of library *A.* Leiningen thankfully warns us in many of these 
situations by suggesting exclusions. However, how can I possibly know that 
something hasn't broken? Stringent testing can give a certain degree of 
confidence that things are still working, but it would seem to me that to 
ensure correctness, we should include *all* versions of the dependencies 
and have the functions link to their respective *versioned* identites. Does 
anyone have advice on how they solve these kinds of problems on their 
codebases in the wild? Thankfully nothing has broken yet (to my knowledge), 
but it seems we have very few assurances here and the best we can do is 
*hope* nothing is broken. Any advice is much appreciated.

Thanks,

Arthur

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.