Pruning modules

[Fredrik Ekholdt]

In Ivy for example there you can choose which strategy it should use to check whether a version of a module is older or newer. 

This is the root cause of a lot of issues on Ivy.

I was wondering if it would be a good idea that a module in adept states which module it replaces. This way it would be deterministic how a module will act and it would support org/name changes as well. 

What do you guys think?

[Fredrik Ekholdt]

In retrospective I realize that defining the modules that replace other will break if you have different versions of stuff in different repositories. 

So, do we have to do this in the same as Ivy and compare version strings or do we do it some other way?

F

[Mark Harrah]

On Sat, 13 Apr 2013 03:54:47 -0700 (PDT)
Fredrik Ekholdt <fre...@gmail.com> wrote:

> In retrospective I realize that defining the modules that replace other
> will break if you have different versions of stuff in different
> repositories.
> So, do we have to do this in the same as Ivy and compare version strings or
> do we do it some other way?

My opinion/proposal was in my NEScala talk and in this thread:

https://groups.google.com/d/msg/adept-dev/sy3C_iLcags/-7CSHwkasW4J

The idea is similar to yours at a high level. We both want the producer to explicitly specify what is compatible instead of relying on an implied version structure and/or consumer-side version ranges. I proposed having compatibility be in explicit version attributes (see the proposal page and the other thread).

One problem was that if you have multiple version attributes, what does your path look like in the repository? However, if you have one file for all versions, you don't need a separate path for each version and that problem goes away.

-Mark