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

Add dependencies even if strictness == 3 #1766

Merged
merged 2 commits into from
Nov 3, 2015
Merged

Add dependencies even if strictness == 3 #1766

merged 2 commits into from
Nov 3, 2015

Conversation

mcg1969
Copy link
Contributor

@mcg1969 mcg1969 commented Nov 2, 2015

This directly addresses #918, and is now more reasonable in light of the performance improvements provided by #1702 ...

This directly addresses #918, and is now more reasonable in light of the performance improvements provided by #1702 ...
@mcg1969
Copy link
Contributor Author

mcg1969 commented Nov 2, 2015

A test is failing, but for exactly the reason it should: because it is including additional dependencies. I'll double-check the results manually and modify the test code.

@mcg1969
Copy link
Contributor Author

mcg1969 commented Nov 2, 2015

This fix does balloon the number of dependencies pulled in. I think that's because generate_version_eq is bypassing the pruning step. So this doesn't necessarily reflect a significant degradation of performance in active use.

@mcg1969
Copy link
Contributor Author

mcg1969 commented Nov 2, 2015

I'm going to modify the tests another time, this time to use get_dists(specs, filtered=True). Stay tuned.

@mcg1969
Copy link
Contributor Author

mcg1969 commented Nov 2, 2015

OK, I made the filtered=True change locally, but I'm not going to push it up. Here's why: the pruning pass is so good that it effectively renders this test useless. That is to say, generate_version_eq returns an empty list in the include0=False case. So it's better to leave the unfiltered case in the test, so that it properly exercises things.

Bottom line: we should go ahead with this, under the reasonably safe guess that the new pruning pass has resolved the performance issues that dictated the hack/bug in the first place.

@pelson
Copy link
Contributor

pelson commented Nov 3, 2015

Given there is a simple revert strategy if this results in a major degradation in performance, and this is clearly a bug fixed, I'm 👍

@dhirschfeld
Copy link
Contributor

The AssertionError/MatchSpec bug has been a huge source of completely inscrutable install issues for me so I'm +:100: on getting this fix in a release soon!

msarahan added a commit that referenced this pull request Nov 3, 2015
Add dependencies even if strictness == 3
@msarahan msarahan merged commit 74f2909 into conda:master Nov 3, 2015
@msarahan
Copy link
Contributor

msarahan commented Nov 3, 2015

Thanks, @mcg1969

@whitequark
Copy link

Any idea when this will be in a released version?

@rekcahpassyla
Copy link

We may need this enough to go with a non-released build for a bit.. I tried to build using https://github.com/conda/conda-recipes/tree/master/conda but ran into lots of problems. Is there documentation about how to build locally?

@pelson
Copy link
Contributor

pelson commented Nov 5, 2015

Did this recently for py3k on the raspberrypi. Take a look at https://github.com/pelson/raspberrypi-conda-recipes/tree/master/recipes/conda.

@rekcahpassyla
Copy link

@pelson Thank you, will try to adapt that.

@rekcahpassyla
Copy link

Just noticed https://github.com/conda/conda/releases/tag/3.18.4 - many thanks.

@asmeurer
Copy link
Contributor

Glad you were able to change this. You probably should add the test from 3077dc1.

@mcg1969
Copy link
Contributor Author

mcg1969 commented Nov 10, 2015

Ah, great, thanks!

@github-actions
Copy link

github-actions bot commented Oct 7, 2021

Hi there, thank you for your contribution to Conda!

This pull request has been automatically locked since it has not had recent activity after it was closed.

Please open a new issue or pull request if needed.

@github-actions github-actions bot added the locked [bot] locked due to inactivity label Oct 7, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 7, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked [bot] locked due to inactivity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants