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

Flintrock's botocore requirements conflict with the AWS CLI #201

Open
ncherel opened this issue Jun 28, 2017 · 5 comments
Open

Flintrock's botocore requirements conflict with the AWS CLI #201

ncherel opened this issue Jun 28, 2017 · 5 comments

Comments

@ncherel
Copy link

ncherel commented Jun 28, 2017

It's currently impossible to have both awscli and Flintrock working because they require different botocore versions.
Flintrock requires 1.5.10
aws cli requires 1.5.76

Would it be a good idea to loose requirements for botocore as awscli/botocore are often updated and require the last version?

@nchammas
Copy link
Owner

This is a good question.

The way I've understood it from looking at other projects is: It's best to pin your dependencies when you are distributing an application and best to be as flexible as possible when you are distributing a library. The idea is that every application is its own island, whereas libraries need to play well with one another.

I run Flintrock from a virtual environment, but I gather from your question that you probably installed both Flintrock and the AWS CLI to your system's site packages. Is that correct?

I'm not sure what's best to do here. I can loosen the requirement for botocore, but I don't want to go down the path of trying to accommodate other applications or libraries that have conflicting dependencies. It's tough, and I don't envy any library maintainer their work in this regard. Semantic versioning, in practice, is no guarantee that supposedly compatible versions will be compatible, and in the past I've had to revert PATCH release version bumps for some of Flintrock's dependencies because they introduced bugs.

@serialx, @BenFradet, and others reading along - Do you have any thoughts on this? I'm inclined to just say "Please run Flintrock from a virtual environment", but I wonder if there is a better way that doesn't require too much juggling with the dependencies.

@ncherel
Copy link
Author

ncherel commented Jun 30, 2017

I understand this is not a simple issue and that pinning dependencies make it really easier to have a working application. And I've seen that you ran into troubles with the other dependencies.

Yes indeed I've installed both to site packages because I wasn't suspecting that I would need a virtual environment. I can live with that but I wasn't expecting, given that flintrock and aws cli are used for similar purpose, that they would be incompatible.

I have no solution to offer, that's an humble question and also just to warn you that currently, installing Flintrock will break aws cli if you are careless (and vice versa)

@nchammas
Copy link
Owner

If necessary, I can loosen the botocore requirement to accommodate just the AWS CLI, but that will only be done on a best effort basis and not as a guarantee of compatibility. And I am also not inclined to accommodate any other applications which may have conflicting dependencies.

Let me meditate on this for a few days and make a decision. 📿😑

@dm-tran
Copy link
Contributor

dm-tran commented Jun 30, 2017

My team members and I are using the standalone version of Flintrock. This avoids potential conflicts with python packages installed on each computer.

I prefer pinning the botocore dependencies to avoid potential bugs.

@nchammas nchammas changed the title Botocore requirements aws-cli Flintrock's botocore requirements conflict with the AWS CLI Jul 1, 2018
@nchammas
Copy link
Owner

nchammas commented Jan 8, 2021

Another solution I can offer to others facing this problem is to install Flintrock using pipx. It will install Flintrock into an isolated virtual environment, and optionally make it available on your PATH.

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

No branches or pull requests

3 participants