Support .env files or a local twine config file
thet opened this issue · comments
Is there an existing issue for this?
- I have searched the existing issues (open and closed), and could not find an existing issue
What keywords did you use to search existing issues?
.env
dotenv
config
Please describe the problem you are attempting to solve with this request
We have some repositories which should be deployed to different pypi servers. Sometimes it happens that when releasing a packages it lands on the wrong pypi server, which is then a hazzle to fix.
How do you think we should solve this?
Twine already supports environment variables to override the default pypi server.
It would now be very handy to be able to define a .env file which Twine would read and use it's environment variables.
A downside is that .env files are normally not meant to be checked into a repository.
Maybe a better approach would be to support a local .twine configuration file which where one could define the pypi server to use.
I'm aware that twine already supports an alternative .pypirc file via the --config-file argument. But my suggestion is that twine would use a local .env or .twine config automatically, so that Twine intergrates better with other tools using Twine, like https://github.com/zestsoftware/zest.releaser/
Anything else you'd like to mention?
No response
We've rejected project local configuration before I believe and my position on that hasn't changed. We already auto detect the .pypirc config file and like you said support you putting a config file wherever you like with the command-line option. The functionally exists even if it's not magical like you want. You're just offloading the need to understand which config file is used or what attributes of which are used to every user rather than keeping things explicit as we have been doing.
We're also not attempting compatibility with any other tool aside from some convenience compatibility with pip.
Twine detects the .pypirc config file in the home directory, right? It's not cascading multiple pypirc files up the directory tree until the home directory, right?
If it would, that would help me in automating the process and make it obsolete to always remember the --config-file option. Having to remember this option does not solve the problem of accidentally choosing the incorrect pypi server when releasing.
But no problem if this request is rejected. I'll use a combination of the direnv tool and local .env files to solve it or maybe add a release target to the project's Makefile.
Twine detects the .pypirc config file in the home directory, right? It's not cascading multiple pypirc files up the directory tree until the home directory, right?
Correct on both accounts