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

Allow to ignore upper bounds (on dependencies) #238

Closed
hasufell opened this issue Mar 17, 2017 · 7 comments
Closed

Allow to ignore upper bounds (on dependencies) #238

hasufell opened this issue Mar 17, 2017 · 7 comments

Comments

@hasufell
Copy link

Upper bounds are often ignored in (source) distros, because they make the depgraph explode and often turn out to be just "wrong" (as in: too conservative). Coconut currently fails at runtime when upper bounds are not met.

@hasufell hasufell changed the title Allow to ignore upper bounds Allow to ignore upper bounds (on dependencies) Mar 17, 2017
@evhub
Copy link
Owner

evhub commented Mar 17, 2017

@hasufell Which dependencies are you worried about? PyParsing needs its upper bound, for example, since Coconut is very sensitive to minute changes in the PyParsing API. The others can probably live without, though.

@evhub evhub added this to the v1.2.3 milestone Mar 17, 2017
@hasufell
Copy link
Author

PyParsing needs its upper bound, for example, since Coconut is very sensitive to minute changes in the PyParsing API.

Well, shouldn't that be expressed in the test suite then instead of conservative upper bounds? Source distros use test suites and abort package installation if it fails.

@evhub
Copy link
Owner

evhub commented Mar 17, 2017

@hasufell Coconut's test suite is way too large to run in its entirety on installation--the full thing can take up to 30 minutes. Version-checking is fast and easy. Like I said, for any dependency but PyParsing, though, I'd be willing to relax the constraints, though the upper bounds are already looser for everything else. I would add a way to optionally ignore them, but I don't know of any way for pip to support that.

@hasufell
Copy link
Author

well, I don't use pip, as a hack: a magic environment variable could do

@evhub
Copy link
Owner

evhub commented Mar 17, 2017

@hasufell As a hack, yes, that would work--I'd rather not add something hacky like that without a compelling use case, though--what specific error are you encountering?

@hasufell
Copy link
Author

Nothing right now, but I want to drop the upper bounds from the package. I can't do that when coconut bails out at runtime though. Testing is done distro-internal

@evhub evhub removed this from the v1.2.3 milestone Mar 17, 2017
@evhub evhub modified the milestones: v1.3.0, v1.2.3 May 3, 2017
evhub added a commit that referenced this issue May 4, 2017
@evhub
Copy link
Owner

evhub commented May 4, 2017

@hasufell I have removed all of the unnecessary upper bounds, which should hopefully resolve any concerns about this. Currently in develop, will go out in the next version.

@evhub evhub closed this as completed May 4, 2017
@evhub evhub added the resolved label May 4, 2017
@evhub evhub mentioned this issue May 12, 2017
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