-
Notifications
You must be signed in to change notification settings - Fork 49
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
cannot locate theory in included dir #659
Comments
This is only a problem if you namespace the include, right? (in other words: your command works if you do not include the |
Indeed. |
Alright, so I had looked into this about a year back, and could not think of a workflow that would make this a bug rather than a quirk. It is, in fact, quite a bit more complex than the situation you describe because of interactions between namespacing and recursive loadpath—you could It made sense to me at the time that a decision had been made (theories included in namespaced loads are not accessible without namespace, non-recursive namespaced loads take precedence over recursive namespaced loads, namespaced loads at the same level of recursiveness are processed earliest-first), that it was being applied consistently across all ways of extending the loadpath, and that it only needed to be documented. (Which, of course, I didn't do—sorry!) I really do not see a change that would make a single theory accessible as two different names as good. But I'm not sure the view is entirely with merit. |
For more context on my workflow: I am developing jasmin's eclib, which I also want to use (to test it). There are of course multiple fairly easy ways for me to work around the issue. The most annoying is probably the not-so-informative error message, on top of a somewhat surprising behavior: I didn't expect that adding a directory to what looks like a "search path" would make files "disappear" (and that wasn't helped by having the Regarding the fundamental issue of having a single theory accessible under two different names, I'm not sure if that would be a problem for easycrypt. |
The namespacing implementation of EC needs to be revisited -- we currently do not keep the namespace information internally. I'll see if I can fix this issue quickly though. |
Perhaps a first bit of progress here would be for |
What do you mean by "the source of each line"? |
Whether a path was added by command line, easycrypt.config or easycrypt.project. |
Back to this: this is a bug. When adding a directory to the include path, that is a duplicate check. However, this check does not take the namespace into account. |
@cassiersg Can you check that you are happy with the fix? |
@strub Yes, it fixes my issue. Thanks! |
It seems that if a directory is included with the
-I
flag (oridirs
ineasycrypt.conf
), then it cannot be accessed as a direct "local" require anymore.To reproduce:
a.ec
b.ec
with contentrequire import A.
easycrypt b.ec
workseasycrypt -IX:$(realpath .) b.ec
fails with error messageThis is annoying when simultaneously (i.e., using the same easycrypt config) developing a library and testing its use.
The text was updated successfully, but these errors were encountered: