Issue
Documentation says that any config value can be passed through an environment variable POETRY_<config> as well as secrets for private repos. However, I suspect that the code doesn't process secrets correctly.
Setup:
- There is no
auth.toml file.
- Url for the private repo is added in
config.toml.
pyproject.toml contains url and name for the same private repo.pyproject.toml references one package from the private repo.- Variables
POETRY_HTTP_BASIC_REPO_PASSWORD and POETRY_HTTP_BASIC_REPO_USERNAME are set.
- Variable
POETRY_HTTP_BASIC_REPO is not set.
- Some debug output (
print) is added to poetry source code.
Outcome:
>poetry install --dry-run --no-ansi -vvv
Getting auth for repo
Need to get setting http-basic.repo
Checking variable POETRY_HTTP_BASIC_REPO, value <object object at 0x00000239FFCD5900>, not set <object object at 0x00000239FFCD5900>
Value is not set, so continue
Checking key: http-basic
Will return default: None
Failed to get auth
Using virtualenv: c:\home\anaconda3\envs\env-poetry
Updating dependencies
Resolving dependencies...
1: fact: demo is 0.1.0
1: derived: demo
1: fact: demo depends on treeview (~0.1.0)
1: selecting demo (0.1.0)
1: derived: treeview (~0.1.0)
1: fact: no versions of treeview match >=0.1.0,<0.2.0
1: conflict: no versions of treeview match >=0.1.0,<0.2.0
1: ! treeview (~0.1.0) is satisfied by treeview (~0.1.0)
1: ! which is caused by "demo depends on treeview (~0.1.0)"
1: ! thus: version solving failed
1: Version solving took 0.348 seconds.
1: Tried 1 solutions.
[SolverProblemError]
Because demo depends on treeview (~0.1.0) which doesn't match any versions, version solving failed.
Thoughts:
It looks like get_http_auth expects a dictionary. We can only get a dictionary if we read from the config file, not the environment variable. Or am I wrong here?
I made more experiments around this (like defining POETRY_HTTP_BASIC_REPO with various content), but couldn't get around the fact that auth must be a dictionary.
Variables POETRY_HTTP_BASIC_REPO_USERNAME and POETRY_HTTP_BASIC_REPO_PASSWORD seem never to be read. Only if I reference them with smth like this:
export POETRY_HTTP_BASIC_REPO={http.basic.repo.username} {http.basic.repo.password}
but this gets me nowhere as this is again not a dictionary.
Conclusion
It seems to me that either the code or documentation shall be changed. My suspicion is that the code follows your design and you won't want to change it. So perhaps the documentation shall be a bit more clear about such usage.
This issue is somewhat related to #208 .
I am on the latest Poetry version.
I have searched the issues of this repo and believe that this is not a duplicate.
If an exception occurs when executing a command, I executed it again in debug mode (
-vvvoption).OS version and name: Windows 10, 64-bit.
Poetry version: 1.0.2
Issue
Documentation says that any config value can be passed through an environment variable
POETRY_<config>as well as secrets for private repos. However, I suspect that the code doesn't process secrets correctly.Setup:
auth.tomlfile.config.toml.pyproject.tomlcontains url and name for the same private repo.pyproject.tomlreferences one package from the private repo.POETRY_HTTP_BASIC_REPO_PASSWORDandPOETRY_HTTP_BASIC_REPO_USERNAMEare set.POETRY_HTTP_BASIC_REPOis not set.print) is added to poetry source code.Outcome:
Thoughts:
It looks like get_http_auth expects a dictionary. We can only get a dictionary if we read from the config file, not the environment variable. Or am I wrong here?
I made more experiments around this (like defining
POETRY_HTTP_BASIC_REPOwith various content), but couldn't get around the fact thatauthmust be a dictionary.Variables
POETRY_HTTP_BASIC_REPO_USERNAMEandPOETRY_HTTP_BASIC_REPO_PASSWORDseem never to be read. Only if I reference them with smth like this:but this gets me nowhere as this is again not a dictionary.
Conclusion
It seems to me that either the code or documentation shall be changed. My suspicion is that the code follows your design and you won't want to change it. So perhaps the documentation shall be a bit more clear about such usage.
This issue is somewhat related to #208 .