You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched the issues of this repo and believe that this is not a duplicate.
OS version and name: Debian 10 (buster)
Poetry version: 1.1.4
Issue
I'm unsure this should be considered as a bug.
In poetry.lock, the url field fills packages location. If HTTP authentication is used, the user and password are provided in the URL so it's readable in the file. For example:
[package.source]
type = "legacy"
url = "https://alice:a_passwd@pypi.domain.tld/site/prod/+simple"
reference = "whatever"
It could be replaced by https://**user**:**password**@.... However, I wonder if it's the good strategy because the poetry.lock file can't be used directly to rebuild a virtualenv without doing search/replace those strings. What do you think about it?
I could provide a PR but I prefer to get some feedback before.
My understanding is that poetry.lock is meant to contain all the information necessary to accurately re-create an environment. As such, you can't remove information from it and rely on finding that information somewhere else afterward.
I'd consider this a bug. From my understanding the lock file is something you'd want to share with contributors through SCM. Having credentials in SCM seems like a bad idea. Maybe I have the purpose of the lock file wrong? Is it not supposed to be shared?
Activity
1ace commentedon Feb 2, 2021
My understanding is that
poetry.lockis meant to contain all the information necessary to accurately re-create an environment. As such, you can't remove information from it and rely on finding that information somewhere else afterward.robertlagrant commentedon Apr 18, 2021
Would vote that this is not a bug, but would suggest that in the presence of http auth that a warning is printed to the console.
sblondon commentedon Apr 22, 2021
I like the warning idea. I will see to implement it.
thoward-godaddy commentedon Oct 12, 2021
I'd consider this a bug. From my understanding the lock file is something you'd want to share with contributors through SCM. Having credentials in SCM seems like a bad idea. Maybe I have the purpose of the lock file wrong? Is it not supposed to be shared?
sblondon commentedon Oct 26, 2021
It's the use case that leads to create this issue.