-
-
Notifications
You must be signed in to change notification settings - Fork 27
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
Use --alias key #92
Use --alias key #92
Conversation
Maybe check if an alias already has a |
Sure, I'll continue as I have time, likely later today |
Take your time :) |
Hello, long-winded response to a small issue. After adding the check you mentioned I wanted to know how all these dependency maps are dealt with. What's informing me resolve-deps reference, reference, tools.deps code, code The implementation leads to this general precedence when a single project file declares multiple versions of a library.
So I have learned version conflicts (outside the codebase) aren't an issue except for mental overhead, maybe more if this tool is helping you touch project files less. Plus, a lot more is possible than the 2 or 3 cases I was aware of. -- If I start throwing in more checks, cli flags etc it feels like increased spaghetti for diminished returns. My question for you guys as the designers and maintainers, how fine-grained should neil as a tool aim to be.
The cleanest all-or-nothing approaches are keeping it naive and letting the user handle it manually, or letting them target any flag they want. Specifying anything between those makes neil more opinionated, so I'd like to consult on where the balance is before pushing anything. My first thought before all this was to check for This continues to be an interesting task after getting excited for an analogue to pip install or npm install, lol.... Thanks! |
I agree with this. In my opinion we should keep it simple for now:
For project-level This is just my feedback; hopefully it helps. I'll leave it to @borkdude for next steps here. |
I agree, let's keep it simple, user can always adjust manually but let's also take into account the existing key and use that if present. I don't think {:paths ["src"] ;; project paths
:deps {} ;; project deps
:aliases
{;; Run with clj -T:build function-in-build
:build {:deps {io.github.clojure/tools.build {:git/tag "TAG" :git/sha "SHA"}}
:ns-default build}}} |
Ok sounds good both replies. I'm working on tests and was getting hung up on failures related to searching for licenses, oops.. Then checked github:
Now writing test(s) for alias use cases and finding that |
@kees- Ah right, tests welcome, merged this a bit prematurely :). Yes, this github rate limiting is annoying, but perhaps you can test with a predefined version. |
:deps is not deprecated, it means the alias replaces the top level deps,
which is what you want with eg tools build
On Sun, 14 Aug 2022 at 16:01, Radford Smith ***@***.***> wrote:
Specifying anything between those makes neil more opinionated
I agree with this. In my opinion we should keep it simple for now:
- neil add dep with no --alias always adds to [:deps]
- neil add dep --alias foo always adds to [:aliases :foo :extra-deps]
- Special case: If deprecated :deps key is already present in [:aliases
:foo], use that instead of :extra-deps for compatibility
For project-level deps.edn aliases, :extra-deps is almost always what the
user wants. I think for other cases like :override-deps or :replace-deps
it's reasonable to edit the deps.edn file by hand.
This is just my feedback; hopefully it helps. I'll leave it to @borkdude
<https://github.com/borkdude> for next steps here.
—
Reply to this email directly, view it on GitHub
<#92 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACFSBXQCDIJBE46E4AVET3VZD32FANCNFSM56GHRKBQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Got it, thanks for the clarification. |
#91
This should work. Previously, duplicate dependencies wouldn't be an issue because the commands targeted a single possible key.
My remaining concern is this version of add-deps doesn't address possible duplicates because the location it adds to is conditional. I don't know whether the project's intent would be to ignore a dupe with the same version between
:deps
and an alias, warn, or remove one. So please stress test this!