-
Notifications
You must be signed in to change notification settings - Fork 413
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
beta18 changes how jbuilder handles conflicts between installed and symlinked libraries #562
Comments
The case you describe should still be an error with beta18, I'll have a look. Basically one case we tried to support better is for instance the case of linting in Base:
With beta17, one would have to put in the same workspace Base and all the dependencies of the ppx rewriters in order to lint Base. With beta18, it's not necessary. Though we still check for conflicts when the two versions ends up being used by the same library or executable, since this cannot work. |
BTW, can you give a concrete example (toy example or real project) where you think an error should be reported and isn't? Just to be sure I'm thinking about the right thing |
@diml Sorry for the delay! See https://github.com/hcarty/jbuilder-issue-562 for an example that illustrates the problem. Instructions are in that repo's |
Thanks. Looking at the example, it seems to me that #430 would avoid the issue entirely. i.e. I'm not sure what's the best solution here. Possibly we could make the new behavior opt-in, i.e. in cases such as Base you'd have to write something in the jbuild file of the linter in order to allow it to use the external version of Base. |
I implemented the latter solution in #587 |
fixed in beta19 |
Consider a project
myproject
which usesmylib
andotherlib
.otherlib
usesmylib
internally.mylib
andotherlib
are installed via opam.When developing
myproject
, new changes are required inmylib
. Because jbuilder/dune is super awesome, we can symlink the devmylib
source tree under themyproject
source tree, hack away, and everything almost works great. BUT this is problematic because now themylib
used bymyproject
and themylib
used byotherlib
are different! So that difference needs to be dealt with.Under beta17,
jbuilder
would report that the internal/symlinked version ofmylib
conflicts with themylib
installed under opam as required byotherlib
. An error message is displayed and the build fails with a happy little error message describing the issue. We can fix the issue by symlinkingotherlib
too, appeasingjbuilder
and getting the results we want.Under beta18,
jbuilder
does not report the conflict. The internal version ofmylib
is built butjbuilder
silently compilesmyproject
against the opam-installed version ofmylib
. This causes themyproject
build to fail in an unexpected way because it's trying to use the newmylib
interface which only exists in the internalmylib
, not the opam `mylib.The beta17 behavior was much more friendly - it took me a while to dig out the issue after upgrading jbuilder to beta18.
The text was updated successfully, but these errors were encountered: