Open jacksmith15 opened 11 months ago
Thanks a lot @jacksmith15 for your thoughts on this and #461. I haven't read in much detail, but the situation here is indeed quite messy. I'm going to take a crack right now at upgrading the vendored Poetry. This will hopefully improve the baseline somewhat. Ultimately I think we shouldn't be relying on Poetry, but I'm just going to focus on the upgrade for now...
In case this seems to have dropped off my radar don't hesitate to ping me.
Checklist
What is the idea?
I'd like to improve upon the mechanism for configuring auth for private PyPi repositories.
Why is this needed?
The documentation claims the process for configuring private pypi repositories is simply:
However I believe the process actually looks as follows:
poetry
(matching the vendored version):poetry
:conda-lock
:I think there are a few problems here:
poetry
separately, at a specific version matching the vendored poetry. This negates the value of vendoring in the first place.poetry
, which is effectively an implementation detail ofconda-lock
(currentlyconda-lock
usespoetry
as a resolver under the hood, butconda-lock
should be free to change the resolution algorithm without breaking user workflows).What should happen?
I propose that
conda-lock
provides its own interface for configuring privatepypi
repositories, and then manages the internal gymnastics of providing these to thepoetry
resolver.I propose that this interface supports configuration via environment variable first-and-foremost, as this is the most portable approach for configuration, and supports more secure workflows with tools like envchain.
Additional Context
Note also separate issue https://github.com/conda/conda-lock/issues/461 regarding auth stripping for private PyPi repositories.