seems hacky because it is hacky

Better way would be to copy the function from elm compiler and link back, so if/when it changes we can follow up.

I think the function in compiler must be doing some lookups into the package registry (or versions.dat file?) which we probably don't want to do.

I found some time to have a look in compiler code.

There is a module for working with semantic versions. On top of that, there is a module for working with full constraints. We can essentially bring this code in easily.

When it comes to version resolution, this is being done using solver. This code by definition needs to know about which versions of the package are available. This must be done either from cache or via http request. I suppose this is also related to snapshot command.

• We can enforce snapshot running before convert maybe even adding argument to versions.dat location and read the file
• Merge snapshot and convert commands and produce both elm-srcs.nix and versions.dat at the same time (versions.dat won't use stdout).

I'm going to have a look into how convert and snapshot commands work so I have a better idea what would this mean.

I think using Elm solver is a better approach, although I'm afraid it will bring in a lot of complexity as Haskell modules in Elm are completely custom so you'll have to bring those in as well.

That was my initial approach as well and why I decided to not support libraries.

I'm going to start by moving just version and constraint logic first and then explore what would be required from that point.

I don't think moving any code from compiler will be the way to resolve this. Even just this is quite crazy https://github.com/elm/compiler/blob/master/compiler/src/Data/Utf8.hs It would be probably better to implement custom https://github.com/elm/compiler/blob/master/compiler/src/Elm/Version.hs#L110-L120 that works with String/Text rather than using compiler code with own Utf8 types.

this commit implements compiler style parsing but without custom utf8 types. It's essentially doing still the same thing as before, just in a more complicated way though.

once you have a time please check this @domenkozar. To recap the change:

• we no longer just directly split string by spaces and take first version in here
• we have simplified (using Strings) version of version and constraints code from the compiler
• there is still not version resolution using data from remote (latest available version), just a bit more abstraction for working with version strings.
• it's esentially still does the same thing though it's just "hidden" in new module making it look more abstracted away.

Main questions are:

• Is there a benefit in hiding the string split and deconstruction to version type and back?
• Should I try to include version resolution code somehow (fetching data about latest versions from remote)
  • versions.dat and elm-srcss versions should match as otherwise elm make will attempt to fetch newer version from remote
  • the current workaround that works is to specify lowest version as 1.0.1 <= ... instead of 1.0.0 <= ..

given the limitations, it might be a good idea to commit this file instead.

@domenkozar just want to highlight this ☝️ In my opinion this is the most real blocker for merge now. If new elm/core gets published this generates newer versions.dat and elm compiler starts fetching lib in elm make phase (installPhase) which would make tests broken for people with useSandbox = true

Sounds good to commit this :)

this applies only in if we won't bring the whole solver and instead download the lowest version from the range.

I think this is the last missing bit, we need to commit elm-srcs.nix and assert the output

Better way would be to copy the function from elm compiler and link back, so if/when it changes we can follow up.