Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
T1mL3arn opened this issue Jan 26, 2024 · 4 comments
Open

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

T1mL3arn opened this issue Jan 26, 2024 · 4 comments

Comments

@T1mL3arn
Copy link

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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants