Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use "devpi login" and "devpi use" data instead of command line args #83

Open
kstrauser opened this issue Jan 25, 2016 · 2 comments
Open

Comments

@kstrauser
Copy link

Whenever I'm using devpi-builder, I've probably already used "devpi login" and "devpi use" to authenticate and set my target index. Could devpi-builder (perhaps optionally) use that information in place of the index, user, and password command line arguments?

@theMarix
Copy link
Contributor

Thank you for your feedback! In fact, devpi-builder could use that information. Internally it uses the original devpi client for communication with devpi and thus if we would not explicitly override the default behaviour it would work out of the box.

The only issue with that feature is that I have a completely different use-case than you do. We mostly use devpi-builder in a CI environment were we want to make sure that concurrent runs don't interfere. The same is true for the underlying devpi-plumber which we use to call the devpi client without the overhead of creating a subprocess. It creates a temporary client directory for each client instance which is thus isolated from that of the command-line devpi client. This library would have to be adjusted, too. Because of our use-cases, however, both devpi-builder and devpi-plumber will also have to be able to support the existing behaviour.

I have already thought about this issue a little and I think it can be done. It does require some refactoring in devpi-builder and devpi-plumber, though, and I will have to put some more thought into it. Do you have any preference on what the CLI should look like to support both use cases?

@kstrauser
Copy link
Author

Your use case is interesting, and now that you mention it, something we'd also want to use soon. That makes it probably a lot less useful than I'd originally thought.

Out of curiosity, how do you manage your credentials in CI? My original thought was to manually do a "devpi login" and let Jenkins use the stored creds. I'd prefer it if every Jenkins user didn't need access to that password, so we could probably write a wrapper script that invokes devpi-builder with the appropriate arguments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants