[provider: pypi] Unable to use tokens on some repos with small keys

[jaraco]

Reported in travis-ci/travis.rb#221, some repositories have a short encryption key, so short that it can't encrypt a PyPI token. As DPL requires the password be provided in the travis config yaml (docs indicate minimal config includes a password), it's not possible (as far as I know) to use the workaround, setting the value in an env var, without also not using DPL. My main workaround has been to stop using DPL and just maintain a tox config to upload releases, one that honors the TWINE_PASSWORD environment variable. Perhaps DPL should honor this mode too so that user's aren't trapped by the travis.rb bug.

[svenfuchs]

Thanks for reporting this, @jaraco

Dpl v2 accepts environment variables on all providers. For pypi these are prefixed PYPI_. See https://docs.travis-ci.com/user/deployment-v2/providers/pypi#environment-variables and https://github.com/travis-ci/dpl#pypi

If you are running this on Travis CI you can opt in to v2 (currently in dev preview release https://blog.travis-ci.com/2019-08-27-deployment-tooling-dpl-v2-preview-release) by adding this to your .travis.yml:

deploy:
  - provider: pypi
    edge: true

If you are using dpl outside of Travis CI you can install the preview release using:

gem install dpl --pre

Please let me know if this works for you. I'll close this ticket here. Please feel free to reopen if needed.

[webknjaz]

@svenfuchs FWIW I still don't like having a global env var accessible to all test steps, that's why I usually prefer setting it in the YAML config so that it's only available to the deployment provider.

Also, consider another scenario: I want to publish the dist to two different PyPI servers, hence two different tokens. With a global env var, it's not possible to do this.

@jaraco I think it's been reported a few times already: pypi/warehouse#6287 / pypi/warehouse#6338 / pypi/warehouse#6355. But I haven't hit this myself. Maybe my Travis client is older or maybe my tokens just didn't have those problematic symbols in them.
Have you tried regenerating the token a few times to eliminate this?

@svenfuchs Oh, can this be related to the differences between travis-ci.org and travis-ci.com?

[jaraco]

Have you tried regenerating the token a few times to eliminate this?

I haven't, but my token doesn't contain any of the problemmatic symbols. It's all alphanumeric plus -.

Please let me know if this works for you. I'll close this ticket here. Please feel free to reopen if needed.

Yes, I filed this ticket here because I was unaware of a way to use the travis-recommended workaround for DPL and the v2 answer addresses that concern. Thanks.

I think it's been reported a few times already.

Yes, the problem still exists more broadly, but the root cause isn't with DPL. This report was to DPL itself to address its ability to accept the workaround to use environment variables.