-
Notifications
You must be signed in to change notification settings - Fork 14
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
mranderson rewrites some cljc/clj files twice #72
Comments
Looking at this I realised that the reason behind instaparse having cljc and clj files for the same namespaces is to provide backward compatibility for clojure 1.6 (before reader conditionals). Instaparse does this via https://github.com/aengelberg/cljsee In fact if you look at the source of instaparse before the cljsee magicked uberjar, there is no such duplication: https://github.com/Engelberg/instaparse/tree/master/src/instaparse Based on that I am thinking now that mranderson could actually filter out those excessive clj files and just work with the cljc files for instaparse or more generically for all such projects. There is a risk here of course that I break other project's mrandersoning so I wonder if there is a valid reason to have a cljc file and a clj (or cljs for that matter) for the same namespace. I know it is kinda the policy to have a clj and a cljs file for the same namespace or a single cljc file. no idea if there is a valid reason to have cljc and clj/cljs (apart from cljsee's). maybe @danielcompton if you are available for commenting on this, you could share your opinion? |
created a branch called |
Hi @benedekfazekas, thanks for looking into this. I found these 2 resources on that topic: https://clojure.org/reference/libs#order Given what I'm reading there, I think it's perfectly fine to have even all 3 types of Clojure files in a project. So, if possible I would prefer the approach of correctly rewriting all those files, instead of removing what we think is not needed. WDYT? |
@benedekfazekas I found another issue which might affect you when experimenting with Instaparse. I created an issue for this here just now: #73 |
hm... good finds. maybe your approach is better then. let me have a think about this. on a sidenote the watermark missing could be a separate issue not related to this or your PR. |
hi @r0man updated the |
Hi @benedekfazekas, I just tried it with Instaparse inlined in cider-nrepl and it seems to work! Thanks for taking a look at this. |
glad it worked, will add the fix and do a snapshot release to unblock your cider-nrepl work, still thinking about #73 but suppose that is not really a blocker for you, is it? |
Ok, thanks for your help! Much appreciated. No, I don't think this isn't a blocker. I will also still need a bit more time with the stacktrace stuff anyway. |
coolio i might try to fix #73 as well and snapshot release them together |
fixed with 718ef4a |
from @r0man 's PR #71
Hello,
I would like to use Instaparse in Orchard and Cider as a dependency to
parse stacktraces formatted by Aviso, Clojure and Java, and show them
in the Cider stacktrace inspector.
In order to include Instaparse into the Cider middleware I think it
must be shipped as a inlined dependency produced via mranderson.
Unfortunatly, mranderson wasn't able to inline Instaparse. It replaced
namespace declarations in some of the files twice. The Instaparse JAR
looks like this:
For some namepaces Instaparse has a CLJ and a CLJC file, the
instaparse/line-col namespace for example.
During the inlining done by mranderson, I observed the following
behaviour:
Mr Anderson starts rewriting the instaparse dependency
It has a list of files to rewrite, one after the other
It starts rewriting instaparse/line-col.clj
After rewriting instaparse/line-col.clj it rewrites all other
files to refer to this new namespace, including
instaparse/line-col.cljc
When instaparse/line-col.cljc is picked up for rewriting it's
namepace was alreday replaced, but mranderson rewites it again.
The text was updated successfully, but these errors were encountered: