neil dep upgrade
#110
neil dep upgrade
#110
Conversation
|
Working without |
When I run with
neilz dep upgrade :lib djblue/portal :dry-run
, i get these opts:
{:deps-file deps.edn, :lib djblue/portal, :dry-run true}
But when I swap the args around like this:
neilz dep upgrade :dry-run :lib djblue/portal
I don't get a :lib option at all:
{:deps-file deps.edn, :dry-run true}
|
Looks like there's some order sensitivity in the CLI parsing. Moving Example (printing opts at the beginning): This isn't what I was expecting! Perhaps I'm misunderstanding the |
|
I'm getting errors when trying to run the existing tests:
|
|
@teodorlu: I think you may be hitting the GitHub API rate limit. Trying again with a VPN or waiting a bit might fix the issue. |
|
I created a new issue with a possible workaround for the rate limit: #111 |
|
The tests are passing for me locally: |
|
Nice! I'll try again later, possibly double check the Github tokens. |
|
It would also be good if we can enable + document how to run a single test. Running the whole test suite takes time, and I'm mostly interested in the new tests I've written. |
|
Just wanted to say that running tests in a single namespace for Before: half a minute to run tests, didn't see what was wrong. After: can run only my own tests in a second, easily find out where stuff fails. Now I'm actually enjoying working on the tests 😄 |
This test helper now supports the args used by `dep_upgrade_test`, which expected to set the :deps-file and a :dry-run flag. It may be preferred to leave this as is, and instead build up the neil command as a string (rather than support neil's args in this test helper).
|
I opened a PR against this branch here teodorlu#1 that fixes the tests and linter errors. I can also take a shot at merging against the latest to deal with conflicts as well, feel free to ping me if that'd be a help |
|
I tested locally and found this:
|
Also adds a few example usages.
This refactors this test somewhat - the `let` vars were pulled into defs, which makes evaling commands in the tests themselves much easier. A new test was added to be sure specifying a single `:lib` only updates that dep, leaving others as they are. The existing tests were also both using dry-run - they've been refactored to run without --dry-run to be sure things are actually working, except where dry run is being tested explicitly.
Good catch - thanks! |
Writes a few tests to be sure upgrade :git/sha based deps work as expected (i.e. they should not move to :mvn deps).
Adds an additional upgrade test to be sure updating a single lib also maintains the same :git/sha style. Refactors dep-upgrade to check the current dep style (:git/sha vs :mvn/version) so that the same style is used to perform the upgrade. Introduces a few private helpers supporting the upgrade function.
Rather than just return nothing in the success case, prints a line indicating which deps are being updated.
I noticed the :git/tag and :git/sha usage in neil's own deps.edn - relying on :git/url seems problemmatic in that case, so I'm switching to checking for only a :git/sha.
|
The last few commits extend the test coverage to cover single :lib usage, and adds tests + refactors to maintain :git vs :mvn style deps. It also adds Aliases are not yet supported - i'll take a shot at that next. One thing I'm not confident on is :git/tag usage - i'm not 100% on the expectation for upgrading a dep in the case (i.e. should the tag play into it at all?): The behavior for now assumes you want the latest git sha, so you end up with: That's probably right for now - I'm not sure why both the tag and sha are present in this case (pulled from neil's deps.edn). |
|
What we could do is get the latest tags from github and upgrade to that one? |
|
is there already support for adding a dep at a specific tag? |
|
No, but we could add a |
|
it's probably not too bad to go for now. i'll assume in the :git/tag case we want to ignore the :git/sha in the dep description (i.e. prefer to check for :git/tag first). Hopefully github's api is reasonable to fetch tags with (i can probably model it off the way the shas are fetched). Tho i am slightly wary - is a "latest" tag always a good one (vs something tagged for other reasons)? I suppose for 99% of cases it's probably the right thing. |
neil dep upgrade#107Proposed API:
neil dep upgrade- upgrades all dependencies to the latest versionneil dep upgrade --dry-run- shows all available upgradesneil dep upgrade --lib hiccup/hiccup- upgrades only hiccupneil dep upgrade --dry-run --lib hiccup/hiccup- shows available upgrades for hiccupMain stuff is working.
Remaining tangible problems/questions:
neilz dep upgrade :lib djblue/portal :dry-runparses differently fromneilz dep upgrade :dry-run :lib djblue/portal:aliascorretly, feedback would be good.Remaining fuzzy questions:
Like
neil dep add,neil dep upgradewill give us alpha versions. For instance, we always install alpha versions of hiccup:We could try to do something about this, for example prefer versions that match
#[0-9\.]+. But that's probably best solved in a different issue / PR.