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

cljr-add-project-dependency blows up when parsing Clojar artifacts #255

Closed
andersenleo opened this issue Jun 4, 2019 · 10 comments · Fixed by #256
Closed

cljr-add-project-dependency blows up when parsing Clojar artifacts #255

andersenleo opened this issue Jun 4, 2019 · 10 comments · Fixed by #256

Comments

@andersenleo
Copy link
Contributor

Cross-posting here.

Sorry for skipping the report template - all details should be in the linked Github issue:

syl20bnr/spacemacs#12385

Should also add that I'm running OpenJDK 8 (AdoptOpenJDK).

@benedekfazekas
Copy link
Member

thanks for this. although as this comment says the referenced lib's name is somewhat borked. I suppose if the issue can not be reproduced with well named libs I will close this.

@andersenleo
Copy link
Contributor Author

I understand that approach. At the same time -- if the library was able to be uploaded to Clojars with that format.. wouldn't that indicate that [trident/1.1 "jobryant"] is a valid artifact coordinate and should be "parsable" by refactor-nrepl?

Would it be possible to dump a warning (and ignore) "borked" artifact names when parsing rather than crashing the artifact listing entirely?

@benedekfazekas
Copy link
Member

valid point. not sure it worths the effort tho as naming this artifact "1.1" was almost surely not the intention of the author. Happy to look at/accept a PR for this tho.

@andersenleo
Copy link
Contributor Author

Well - I guess something must be done. The function (which at least I use frequently) is useless until it's either fixed in refactor-nrepl or the library is taken down from Clojars :-)

I'll give the PR a try!

@benedekfazekas
Copy link
Member

ah just realised I misunderstood the situation, sorry. This happens when we retrieve version info from clojars so this brakes the feature for everybody. Also as far as I remember clojars is immutable -- altho this is possible a good case for an exception of this rule.

I would also try to raise this with the author of the lib and maybe clojars maintainers. But PR is still very welcome.

@benedekfazekas
Copy link
Member

Seems the author got notified already jacobobryant/flub#4

@andersenleo
Copy link
Contributor Author

Sweet 👍. PR is inbound in a couple of minutes.

@jacobobryant
Copy link

Hi. Author of the borked lib here. Yes, I accidentally mixed up the artifact-id and version on that one. Sorry about that. Unfortunately I can't take it down from Clojars since they only delete artifacts when they contain vulnerabilities/private credentials.

@jacobobryant
Copy link

jacobobryant commented Jun 4, 2019

FYI, the Clojars docs give the regexes they use to check group/artifact/version here: https://github.com/clojars/clojars-web/wiki/About#what-is-the-legal-format-for-a-group-or-project-name
So I'd recommend updating refactor-nrepl to be in line with that

@andersenleo
Copy link
Contributor Author

Simple hack to work around the issue in the PR above ☝️.

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

Successfully merging a pull request may close this issue.

3 participants