Following this discussion https://github.com/clojars/administration/issues/108, what would you think of the ability to deprecate a group?
My thinking is, if you advice projects to change their groupids, then tooling like antq will be fooled into thinking that no new versions exist for a given project. When in reality they do, just under a different groupid
So perhaps if possible when fetching a dep under "deprecated" groupid, one would see a warning printed. Or if possible, under a 'pedantic' mode one could get a hard failure
antq does a pretty good job of spotting that a dependency moved to a new group ID -- I've seen it recommend updates from seancorfield/project to com.github.seancorfield/project across versions.
how does that work though? There are many groupIds that a project can possibly be upgraded to (I'd love to cc/ the antq author here... forgot his Slack username which is not liquidz apparently?)
A related thought is that recommending the wrong lib can obviously be a security risk
I don't think they're on Slack at all -- but you can always read the source to see how it works 🙂
(! 687)-> cat deps.edn
{:deps {seancorfield/depstar {:mvn/version "2.0.216"}}}
(! 688)-> clojure -M:outdated
| :file | :name | :current | :latest |
|----------+----------------------+----------------------+---------------------------------|
| deps.edn | seancorfield/depstar | seancorfield/depstar | com.github.seancorfield/depstar |
It spots the updated group ID.and then you update the group and run it again:
(! 690)-> clojure -M:outdated
| :file | :name | :current | :latest |
|----------+---------------------------------+----------+---------|
| deps.edn | com.github.seancorfield/depstar | 2.0.216 | 2.1.267 |
Available diffs:
- It does require that a lib was published with the same version under both groups I think...