This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-02
Channels
- # announcements (14)
- # beginners (133)
- # cider (27)
- # cljs-dev (7)
- # cljsjs (13)
- # clojure (105)
- # clojure-dev (58)
- # clojure-italy (1)
- # clojure-nl (17)
- # clojure-russia (33)
- # clojure-spec (5)
- # clojure-uk (154)
- # clojured (1)
- # clojurescript (35)
- # cloverage (4)
- # cursive (35)
- # datomic (58)
- # duct (8)
- # editors (9)
- # emacs (15)
- # events (1)
- # figwheel (47)
- # figwheel-main (132)
- # hyperfiddle (5)
- # immutant (29)
- # instaparse (21)
- # luminus (3)
- # off-topic (5)
- # onyx (5)
- # overtone (5)
- # pedestal (8)
- # re-frame (7)
- # reagent (6)
- # reitit (3)
- # schema (2)
- # shadow-cljs (178)
- # spacemacs (49)
- # specter (2)
- # sql (1)
- # tools-deps (110)
Are there any restrictions to where tools.deps will look for the :sha
provided?
where else would it look other than the git repo?
clj -Sdeps '{:deps {org.clojure-grimoire/lib-grimoire {:git/url "" :sha "767d68f605e5ec2ab740ae42cfc7b90a2948713c"}}}'
This fails with Manifest type not detected when finding deps for org.clojure-grimoire/lib-grimoire in coordinate {:git/url "", :sha "767d68f605e5ec2ab740ae42cfc7b90a2948713c"}
In a more involved setup it fails with the following error/stacktrace :the stack trace is a bit revealing... did you make edits to the file in .gitlibs/libs/...
?
767d68f605e5ec2ab740ae42cfc7b90a2948713c doesn’t look like a commit in https://github.com/martinklepsch/lib-grimoire ?
oh yeah, weird - github didn’t find it
I got your second error trying to run your first command
I didn’t do any manual edits in .gitlibs
(as far as I’m aware at least 😛)
I think the second error is the real error (the MissingObjectEx)
and then after that, it looks like you have a checkout directory, but it didn’t finish so it’s missing files (like the manifest files)
I don’t even know how to jump to source so guess I’m safe 😄
should I try nuking .gitlibs
?
I think you’ll see the same problem again
right, fair enough 🙂
Interestingly there are some files in that SHA’s gitlib dir (LICENSE and README)
yeah, it got part way done
➜ lib-grimoire git:(develop) git cat-file -t c7cd4f50871b20a580a66e77a34bfa9d336fe430
fatal: git cat-file: could not get object info
I guess a) there is either something weird in this repo or a bug in jgit
and b) in this kind of a failure, we should nuke the checkout dir
ticket for b) in https://dev.clojure.org/jira/browse/TDEPS welcome
a) is worth a bit more investigation
maybe there’s a force push or something weird there?
Would love a tarball deps procurer btw 😛
➜ lib-grimoire git:(develop) git cat-file -p HEAD^{tree}
100644 blob 3bc48030cba1b0f250f8b3d2cb0a2635f5195339 .gitmodules
100644 blob 7689f30efd6dcaadfb4033a444fa1c3f1848dba3 LICENSE
100644 blob c87d64a78fcaebbdfe02f188168a3270962869a1 README.md
040000 tree 4c51b4bd0c9980a782b29286cdeefdb49e7bd899 bin #### THIS
100644 blob 54f9aeba51d4b4a61c9ad3de046e770859a217c1 deps.edn
100644 blob f60a2b75223a9c8739d525ea62ba48aeeab878b0 project.clj
040000 tree 97a002c7db97cd89dc74606b77de343d2dbc878d resources
040000 tree 28ffc92968bebaf4930b08ff59d9ff5a3a5c297b src
040000 tree f4581b6f130115e5f0035945fc4ef6036076ba88 test
➜ lib-grimoire git:(develop) git cat-file -p 4c51b4bd0c9980a782b29286cdeefdb49e7bd899 ## Drill in
160000 commit c7cd4f50871b20a580a66e77a34bfa9d336fe430 hooks
100644 blob f3acf21ed723011f2586416e842ce41683bf3f29 install-hooks.sh
The second command cats out the SHA for the tree representing the bin
directory, and it's pointing to a commit blob mysteriously
I did force push to that branch, and it might have even been after I tried to use another revision from that repo — but seems weird that this would still replicate on a system that hasn’t had a clone yet?
I agree with Ghadi that that looks like a bad git structure
Deleted bin/
entirely & commited as 9810f7b20c1a676060f939cfd8f2f785f4dea3c7 but still same issue
did you have something else in mind when you wrote “overwrite”?
oh no wait
seems to work now!
just saw an exception and was assuming it’s the same but it was a different one 🙂
I was just doing that myself :)
gotta say, I’m impressed by your git-fu 😄
you’ve impressively horked this repo, kudos :)
don’t look at me, I’m pretty sure it was @arrdem 🙂
fair enough :)
just change my “you” ref via force-push
an aside to this: are there any plans to add more procurers? A tarball procurer would have been cool in this situation 🙂
I've been hoping that a procurer extension mechanism would appear, off the back of the work to locate the owner of a namespace.
seems pretty far down the priority list
why not just the existing jar support?
👆 this
well, feel free to file an enhancement, preferably with a use case
I can envision how to get a repo into this state via the plumbing api but I find it harder to envision how it happened via the porcelain
I assume some kind of bad rebase
and ghadi, it does seem like Git handles this better than jgit so maybe you’d never even see it shelling out
I’m trying to patch juxt/pack to allow me to pass in an alias to use while generating a jar
this is the relevant bit of code that is catching fire atm:
(let [deps-map (tools.deps.reader/slurp-deps (io/file deps))
resolve-args (tools.deps/combine-aliases
deps-map
(get-in parsed-opts [:options :alias]))]
(tools.deps/resolve-deps deps-map resolve-args)
I’m currently getting:
org.apache.maven.model.resolution.UnresolvableModelException: Could not find artifact org.apache:apache:pom:1
3
@lilactown try adding :mvn/repos to your deps.edn
@alexmiller to solve this, I'm considering inlining the system deps.edn into pack, do you think that would be a problem?
Not as long as you’re willing to roll with future changes
I originally had the system deps baked into boot-tools-deps
then took it out in favor of calling (clojure-env)
to get the list of deps.edn
files to include -- which takes care of the :mvn/repos
issue.
Does pack
not use the system/user deps.edn
files?
@U04V70XH6 I don't want to do that in pack, I explicitly want to ignore the user deps.edn file, and I can't do that without (clojure-env)
returning a map for the deps.edn files it considers.
You could at least assume the first entry in that vector was the system deps tho'...
But that isn't part of the api, it could break at any point. I'd feel like a bad citizen depending on a coincidence rather than a contract.
I thought we were "guaranteed" that the vector of deps files was in order? Or do you mean that whole -Sdescribe
thing isn't documented/guaranteed? /cc @alexmiller
I recall asking and being told the order wasn't guaranteed. I asked when lein-tools-deps did this.
I must admit, I find that very surprising since order does matter ...
@U04V70XH6 but being the first isn't attributed to system in anyway. A least-important override could be added at any time.
you can be guaranteed that they are in order: install, user, project, -Sdeps
however, the last 3 could all independently be either missing or present
and in future the first may possibly not exist
Thank you!
If this guarantee is given, then I think the open ticket to convert it to a map is not needed.
Well, you still couldn't tell the difference between system + user and system + project (except, perhaps, by inspection of the actual paths?) and that was something @U0567Q30W was after I believe.
And you also wouldn't necessarily be able to tell the difference between system + user and user + project at the point where the system deps moved into the library itself (depending on how that is handled).
I think it’s useful to differentiate
for other needs too
Adding a new key to the result of -Sdescribe
with some sort of map explaining where the deps files came from seems useful regardless of other concerns. I think if the system deps file moves into the codebase, then indicating that somehow in the list of config files, with a way to get the raw data structure, will also become important for tooling.
@alexmiller I might be being silly, but I don't see a way in the public api to slurp a dep which is a java.net.URL, e.g. io/resource
. slurp-edn
depends on being a file, and canonicalize-all-syms
is a private function, so I cannot utilize it.
could probably break slurp-edn into something smaller that takes a reader (although the file-ness is being used to construct a good error message there)
canonicalize-all-syms is not public as it may go away
there’s now a canoncialization step built into the extension apis
you can of course invoke it via the private var if you want to call it for now