Support more lax version schemes

[CeylonMigrationBot]

[@FroMage] 1.0 or foo-beta for example. anything really

[Migrated from ceylon/ceylon-runtime#7]

[CeylonMigrationBot]

[@quintesse] Does that mean that we will always have to specify versions? Because this "anything" schema means I could never say module foo, version 2.0+
Also when running from the command line it would be nice if you could just give the name of the module and it will assume you want the latest version.

[CeylonMigrationBot]

[@FroMage] No idea, have to read the spec, but one thing experience shows is that number schemes are infinite, impenetrable and improperly used ;)

[CeylonMigrationBot]

[@gavinking] Currently we do not support version ranges. At some stage in the future I suppose there will be a lot of pressure to do so, but for now it's easier to just not open up this can of worms.

[CeylonMigrationBot]

[@FroMage] In fact what we can definitely do is detect the version if there is only one installed and list the existing versions in the error message if there are more than one

[CeylonMigrationBot]

[@gavinking] Yes, much better!

[CeylonMigrationBot]

[@alesj] For M2, hopefully. :-)

[CeylonMigrationBot]

[@FroMage] Looks like M4 :(

[CeylonMigrationBot]

[@alesj] Version ranges bring a bunch of problems; it's a NP problem. ;-)
I'll see what can be done, but definitely not M3, hopefully M4 ...

[CeylonMigrationBot]

[@gavinking] > Version ranges bring a bunch of problems

I agree. Personally I don't even see this as being on the roadmap for Ceylon 1.0.

[CeylonMigrationBot]

[@alesj] For example; OSGi only recently properly addressed this issue - resolver is now part of the spec; after 10y+.
(of course it was already done before, but in a 1M diff ways)

[CeylonMigrationBot]

[@FroMage] M6.

[CeylonMigrationBot]

[@quintesse] 1.0

[gavinking]

Closing this issue, because it seems to be a request for support for version ranges, but not described very well ;-)

And in the end we chose to go down the path of version overrides* instead of solving the NP-complete problem of version range resolution.

* In 1.4.0 we'll have version overrides in the module descriptor.

[jvasileff]

And in the end we chose to go down the path of version overrides* instead of solving the NP-complete problem of version range resolution.

:(

[gavinking]

Look, I don't actually have a problem with adding support for version ranges, but somebody needs to come up with a proposal that is better than just "more lax".

And by a proposal, I mean something which really addresses the implementation and interop concerns surrounding this.

• It would work nicely across at least JBoss Modules, Jigsaw, npm, Maven, and OSGi.
• It needs an actual algorithm, which might even need to do the exact same thing that OSGi does.
• It would need a reasonable syntax, and I've no clue what that would look like. "1.0."* or something like that I guess.

So, as I say, I'm not against it, but this particular issue isn't helping solve any of the above.

[gavinking]

It would need a reasonable syntax

This is actually pretty tricky, given that we use quoted strings to express versions.

[jvasileff]

It's version resolution w/o ranges that I want (I actually think ranges are misguided).

I'd simply like this work:

module simple "1.0.0" {
    import ceylon.json "1.3.2";
    import com.vasileff.ceylon.structures "1.1.0";
}

But yeah, I agree it's not easy.

[gavinking]

It's version resolution w/o ranges that I want

WDYM?

[jvasileff]

I'd like the module descriptor above to work :)

In this case, ceylon.collection/1.3.2 would be resolved since it is the greater of conflicting dependencies ceylon.collection/1.3.1 and ceylon.collection/1.3.2.

[gavinking]

OIC, so you're saying that com.vasileff.ceylon.structures/1.1.0 imports ceylon.collection/1.3.1?

Actually I guess this is already quite close to working, since @FroMage did some work to resolve conflicts in favor of most recent versions, though I'm not sure if:

• that was only for Maven deps?
• or only for assemblies?

I'm not sure.

The issue with that is what is the policy for deciding which version is "later"?

If there were a robust-enough policy, I would support adding a commandline switch to enable it.

Open an issue if you like. It has never really been requested.

[gavinking]

Hey, at the very least, we could print out a message suggesting the write <set/> element to add to overrides.xml.

[jvasileff]

Open an issue if you like. It has never really been requested

We discussed version resolution in #4240 and I think others, but I'm not sure I want to jump back into the dependency debate with both feet.

commandline switch to enable it

I will say... I think we already have too many command line switches (EE mode, fat jar, and two versions of auto export dependencies with perhaps a third needed). And defaults are all for the least likely settings to succeed. This is particularly bad for dependencies since settings are needed at run time, not just compile time.

But to end on a positive note, I do think that "version overrides in the module descriptor" will make things much better, at least for pure Ceylon apps.