[Feature Request] `lix dev` without touching `./haxe_libraries`

[T1mL3arn]

Having dev lib info separate from haxe_libraries will fix You should avoid commiting this change workflow.

It could be ./haxe_libraries_dev/ or some lix-dev-config.json file, which can be .gitingored. So we can freely experiment with dev libs and have stable ones untouched.

[back2dos]

Hmmmmm. This would allow for a state that has no uncommitted changes and yet leads to different results on different machines, e.g. on the CI, which is somewhat counter to the reproducibility lix strives to guarantee.

The fact that you have to deal with the uncommitted file serves as a reminder that your state is experimental. I can see how that might be a bit annoying, but I would argue that it's far less annoying than getting a cryptic error on the CI for some commit that built just fine for you, just to remember that the discrepancy is some untracked file pointing to a local dev version of a library.

In any case, I'm not against supporting this behavior, but I wouldn't want it to be the default. I wonder how this new behavior could be offered by the CLI without too much awkwardness though ^^

[kevinresol]

I think we should just update the doc and remove that particular sentence. To me lix dev is more like lix local where you point the dependency to a local folder. That can be perfectly valid in some cases for example if you are using submodules as your library.

And I agree that having the CI to fail for a invalid hxml reference would be the desired behaviour in most cases.

[back2dos]

Well. Currently lix dev also generates the warning into the hxml, so it's not really just a matter of docs.

I wouldn't mind having a lix local or something of the sort that points into a submodule or ties together various parts of a monorepo, even if it winds up doing almost the same thing as lix dev.

[T1mL3arn]

but I wouldn't want it to be the default

An option like --use-separate-libs-for-dev would be fine. Use case: you don't want to install many(more than one) instances of heavy libs.