Support for `:local/root` dependencies

[neshtea]

According to the README, dependencies that are required via :local/root are currently not supported (but it is planned to do so at some point). Considering the fact that I depend on some such dependencies, is there a way to still get a build working? A hack would also be fine for now.

What would you suggest? Unfortunately, if this is not possible, for the time being this would be a deal-breaker for me.

While my nix-foo is lacking, I would be glad to help out if you've got any concrete plans.

[jlesquembre]

I've been working on that, I had to rethink my approach and I'm updating the lock file format.

I cannot promise anything, but I'll try to release a next version soon (this or next week).

Thanks for offering support, something that would help is to share any open source project with local/root dependencies to make more tests. Right now, I'm testing the new approach with clojure-lsp, but I'd like to check if it works with other open source projects too.

[john-shaffer]

salmon uses local/root, and I can help tweak/troubleshoot any issues.

[jlesquembre]

I did some progress in the next branch, I added local deps and aliases support. The lock format is different, you can recreate it with:

nix run github:jlesquembre/clj-nix/next#deps-lock

I also updated the demo project, the next branch, to use this new version: https://github.com/jlesquembre/clj-demo-project/tree/next

I want to do more tests before merging it

[john-shaffer]

I got it working with #9 and some changes to my code to avoid these limitations:

1. The main-ns must be in the root deps.edn's source path, not a :local/root dep.
2. The :local/root deps must not themselves have :local/root deps.
3. The main-ns must (transitively) require any namespaces that will be needed. Otherwise, requiring at the REPL doesn't work, and presumably requiring-resolve won't either.

1 and 2 should not be a problem for orthodox polylith projects. They were pretty easy to work around for me.

[jlesquembre]

Thanks for giving it a try!

About the limitations:

1. Not sure about this one, but if that's something supported by tools.deps, I'd like to support it too
2. I didn't test that case, I was expecting it to work. I consider it a bug, I'll fix it
3. I saw that salmon didn't have a -main. That's is required by mkCljBin (what function should be called if not?) Could you explain what is your use case? The only use case I can image for libraries (like salmon) is to generate a jar (to be uploaded to clojars or distributed some other way)

I'd like that any project can use clj-nix without requiring any changes (other than adding a flake.nix file)

I wrote #10 about the next steps, any feedback or suggestions are very welcome. I'm especially interested in what you tried to accomplish on 3, I have the feeling that I could be missing something.

[neshtea]

That's is required by mkCljBin (what function should be called if not?) Could you explain what is your use case?

This didn't come from originally, but I can imagine a use-case: The official guide to Clojure tools deps shows you that to run a program, you should do something like

clojure -X <project-name>.<core-namespace>/run

assuming there is a run function in that namespace. See this section in the guide. I guess this might lead many people to do something like this.

[john-shaffer]

3. I was testing on the clj-nix branch, where I did add a -main. I probably won't use clj-nix for salmon, but it makes a useful open-source test case. I want to use clj-nix on closed-source projects with a similar deps structure.

[jlesquembre]

3. I was testing on the clj-nix branch, where I did add a -main. I probably won't use clj-nix for salmon, but it makes a useful open-source test case. I want to use clj-nix on closed-source projects with a similar deps structure.

@john-shaffer Makes sense. Just to be sure, on those closed-source projects you have a -main, right?

[jlesquembre]

@neshtea I'm not sure if makes sense to add support for clj -X .... I use the -X option a lot to run helper functions locally, but I don't think it makes sense to nixify those. That said, adding support for it is trivial

[john-shaffer]

@john-shaffer Makes sense. Just to be sure, on those closed-source projects you have a -main, right?

Yes, that's correct.

[jlesquembre]

:local/root dependencies should work in the latest version (main branch) :) I tested it a bit with salmon here: https://github.com/jlesquembre/salmon/tree/clj-nix. So far, looks good.
I'm closing this issue, but feel free to open a new one if you notice any problem.

[volisoft]

Seems like relative paths in :local/root is not supported. Here's an example project. Here's the error indicating that local library at ../../components/liba cannot be found:

       last 10 log lines:
       > no configure script, doing nothing
       > Running phase: preBuildPhase
       > Running phase: buildPhase
       > Picked up JAVA_TOOL_OPTIONS: -Duser.home=/nix/store/33qbkrdp0hij5x5iq0xljqw6i36zgld4-clj-cache
       > check com.demo.liba.interface for :gen-class
       > Execution error (ExceptionInfo) at clojure.tools.deps.extensions.local/ensure-file (local.clj:41).
       > Local lib com.demo/liba not found: /components/liba

Such relative paths are supported by Clojure deps and are common in polylith projects.