search

lix-pm / lix.client

A dependable package manager for your Haxe projects
The Unlicense
119 stars 24 forks source link

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

Open T1mL3arn opened 8 months ago

T1mL3arn commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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.