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

Support updating libraries to the latest version #376

Closed
tengstrand opened this issue Oct 25, 2023 · 6 comments
Closed

Support updating libraries to the latest version #376

tengstrand opened this issue Oct 25, 2023 · 6 comments

Comments

@tengstrand
Copy link
Collaborator

tengstrand commented Oct 25, 2023

Today we can execute poly libs :outdated to show outdated libraries, e.g.:

libs-outdated

This is helpful, but the tool doesn't update the files for us. That we have to do manually.

Here we suggest that poly libs :update should update all the libraries to the latest version in all deps.edn files. This can be implemented by using the antq.api/upgrade-deps! function.

It should be possible to leave the library version for bricks and projects untouched, by adding a :keep-lib-versions key to :bricks or :projects in workspace.edn:

:bricks {"shell" {:keep-lib-versions [org.jline/jline]}}
@tengstrand
Copy link
Collaborator Author

I was thinking if maybe poly libs :bump would be a better name of the argument, because it says more about what it does. What do you think @seancorfield?

@seancorfield
Copy link
Contributor

I'm not sure that "bump" conveys the meaning in all languages/cultures -- I think "update" is clear and simple (even tho' I would never use this feature).

@ieugen
Copy link
Contributor

ieugen commented Nov 10, 2023

(even tho' I would never use this feature).
You are too safe @seancorfield . Live a little 😁

I wouldn't use this either - not often at least - I do check release notes and change logs for breaking changes and run the tests after each library update (or a couple if they are small).

@marksto
Copy link
Contributor

marksto commented Nov 15, 2023

@tengstrand hi! Just tried this out and it's a real timesaver for a mid-to-big workspace. Thanks a lot! 🙏

Still, it was not able to update the (root) development project deps.edn, either across its aliases, or at all.
I still have a lib of different versions in :aliases > :dev > :deps and :aliases > :test > :extra-deps. Is it by design?

@tengstrand
Copy link
Collaborator Author

Thanks for reporting this @marksto. Happy to hear that you like it, except for the bug of course! I'm working on a fix already and will post here when it's done.

@tengstrand tengstrand reopened this Nov 16, 2023
tengstrand added a commit that referenced this issue Nov 19, 2023
Issue #376
* Set :latest-version in :lib-deps for outdated libraries.
* Fixed issues in 'libs :update' + support subset of libraries to be updated.
@tengstrand
Copy link
Collaborator Author

I have pushed a fix to master, so please try it out @marksto (and others!).

Now it's possible to update a subset of libraries, by giving the libraries: argument to the libs command.
I don't know if that could be useful for people that don't want to update all libraries, e.g. @seancorfield.

If executed from a shell, then outdated libraries will be suggested when giving libraries: (it may take a second or two, to retrieve them).

If you want to experiment with this feature from the shell, e.g. by changing a library to an older version, then you need to execute switch-ws to refresh the workspace (otherwise it will not detect the change).

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

No branches or pull requests

4 participants