Configure private PyPi repositories in the environment #471
Conversation
✅ Deploy Preview for conda-lock ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| factory.create_legacy_repository( | ||
| {"name": source[0], "url": source[1]["url"]}, config | ||
| ) |
There was a problem hiding this comment.
I've left the previous method here so this is not a breaking change.
However since this is exposing an implementation detail as an interface, it might be worth adding a deprecation warning?
There was a problem hiding this comment.
I'm wondering if we're ready yet to deprecate it. I'm very eager to ditch anything Poetry-related, but setting up environment variables can be a pain, and until we get something better in place, some people may prefer the Poetry interface.
| factory.create_legacy_repository( | ||
| {"name": source[0], "url": source[1]["url"]}, config | ||
| ) |
There was a problem hiding this comment.
I'm wondering if we're ready yet to deprecate it. I'm very eager to ditch anything Poetry-related, but setting up environment variables can be a pain, and until we get something better in place, some people may prefer the Poetry interface.
| factory.create_legacy_repository({"name": name, "url": url}, config) | ||
| for name, url in _parse_repositories_from_environment().items() | ||
| ] + [ |
There was a problem hiding this comment.
Could you please write a test for _prepare_repositories_pool to exercise this functionality?
| Alternatively, you can use the `poetry` configuration file format to configure private PyPi repositories. The configuration file should be named `config.toml` and have the following format: | ||
|
|
||
| ```toml | ||
| [repositories.example] | ||
| url = "https://username:[email protected]/simple" | ||
| ``` | ||
|
|
||
| The discoverable location of this file depends on the operating system: | ||
|
|
||
| - **Linux**: `$XDG_CONFIG_HOME/pypoetry-conda-lock` or `~/.config/pypoetry-conda-lock` | ||
| - **OSX**: `~/Library/Application Support/pypoetry-conda-lock` | ||
| - **Windows**: Check output of `python -c 'from conda_lock._vendor.poetry.locations import CONFIG_DIR;print(CONFIG_DIR)'` | ||
|
|
There was a problem hiding this comment.
@maresb I have restored documentation for the existing repository configuration method here.
Since the previous documentation was incorrect, I have changed the documented process for configuring it this way. This is because the poetry config repositories.foo will write configuration to the wrong appdirs directory for conda-lock to discover (~/.config/pypoetry vs ~/.config/pypoetry-conda-lock).
I have also written it in a way which avoids users needing to install the exact version of poetry vendored by conda-lock.
Also note: I couldn't decipher which directory to recommend for windows, as I suspect its platform-dependent, so that's the best I could do. The old documentation didn't have this problem for the same reason it didn't work.
There was a problem hiding this comment.
Thanks a lot for catching this! Seems like we broke this in #342.
|
@maresb thanks for the review, and apologies for the delay in updating. I think I've addressed all of your previous feedback now 👍 |
|
Hey @jacksmith15, I feel really bad for doing this, but after taking a fresh look I think we are on the wrong track here. 😢 I should have caught this earlier in the review process, my bad. I think a much better approach would be a parallel implementation of authenticated channels where the corresponding documentation would be essentially identical, but substituting Do you agree? If so, would you have any time to rework this into a (partial) implementation? I'm terribly sorry about sending you down the wrong track. Please let me know if I can do anything to help. |
|
To be clear, the suggested approach would involve adding a new non-standard key to the source channels:
- https://host.tld/t/$QUETZ_API_KEY/channel_name
- conda-forge
repositories:
- https://$MY_USER:[email protected]/pypi/simpleDoes that look right to you? I note this doesn't support naming repositories, which is how they are generally supplied to the poetry solver. Should they be auto-named, or break the structural convention in the file? Should this also provide a mechanism for enabling/disabling PyPi? Similar to Additionally, should |
|
These are very good questions. You are understanding my proposal correctly. We already have a precedent for defining a non-standard key in I personally would prefer to be more specific with the key name and have it be I think it's important to avoid Poetry's influence which may push us towards bad design decisions, so I'd prefer autonaming to having a discrepancy between channels and repositories. Do you foresee any problems that might arise with this approach? A mechanism for disabling PyPI outside of Supporting |
|
@maresb regarding the naming, its actually a little tricky to give a good name for Python repositories. I think the most "correct" term is "python simple repository": https://packaging.python.org/en/latest/specifications/simple-repository-api/#simple-repository-api
However I'll prefer |
|
@jacksmith15, I agree that I think |
|
📝 I haven't forgotten about this! I am working on the alternative solution in #481 There's some differences with pip repositories compared to channels that need handling, but I the general direction seems 👍 |
|
Superseded by #529 |
Description
Resolves #460
This PR adds support for configuring private PyPi repositories via environment variables. This avoids users needing to install an exact version of
poetryto manage the configuration format, and then copy around credential files to make them discoverable toconda-lock. See #460 for full reasoning.After this change, users are able to set the
CONDA_LOCK_PYPI_REPOSITORY_<repository-name>environment variable to configure new PyPi repositories.An alternative could be to support
PIP_EXTRA_INDEX_URLinstead, as this will be respected duringconda-lock install, meaning only a single environment variable is required for both lock and install.