This thread has illuminated something that wasn't at all clear from your
original post: namely that all tooling can continue exactly as-is, just
with user tokens swapped for passwords, and no code changes are required.
If all it takes is for users of Clojars to set CLOJARS_PASSWORD to a token
Thanks for the feedback Sean. In my experience, it doesn't matter if
you give users a week, a month, or a year to switch - the majority
won't until their first password-based deploy fails. And to be clear -
all a user has to do is log in to Clojars, create a token, and use the
token string in
D’oh, please disregard. After reading the docs, I see that no changes would be
needed, apart from updating the docs.
Mea culpa, sorry for the noise.
Erik.
> On 18 May 2020, at 07:38, Erik Assum wrote:
>
> I think I agree with Sean that the time frame is a bit short. One thing is
> making
I think I agree with Sean that the time frame is a bit short. One thing is
making deps-deploy
(and also pomegranate) work with tokens (which I’m confident I can handle).
Another thing is that I would imagine both leiningen and boot would need new
releases and people would need to adopt those
Here's a project that is documented to use the Clojars password and is
fairly widely used: https://github.com/slipset/deps-deploy -- all projects
created by clj-new rely on this and all of them will have the same
documentation to use the Clojars password.
Forcing everyone to change their
Howdy folks!
Just letting you know that Clojars[1] now allows you to create and use
deploy tokens[2] in place of passwords when deploying. If you don't
deploy OSS projects to Clojars, feel free to stop reading now.
The deploy tokens are to be used in place of a password when
deploying, and can
