-
Notifications
You must be signed in to change notification settings - Fork 24
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
Comments
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 ^^ |
I think we should just update the doc and remove that particular sentence. To me And I agree that having the CI to fail for a invalid hxml reference would be the desired behaviour in most cases. |
Well. Currently I wouldn't mind having a |
An option like |
Having dev lib info separate from
haxe_libraries
will fixYou should avoid commiting this change
workflow.It could be
./haxe_libraries_dev/
or somelix-dev-config.json
file, which can be.gitingore
d. So we can freely experiment with dev libs and have stable ones untouched.The text was updated successfully, but these errors were encountered: