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

--ignore-installed and dependency resolution #5046

Open
pradyunsg opened this issue Mar 1, 2018 · 6 comments
Open

--ignore-installed and dependency resolution #5046

pradyunsg opened this issue Mar 1, 2018 · 6 comments
Labels
type: maintenance Related to Development and Maintenance Processes

Comments

@pradyunsg
Copy link
Member

I tried looking for why it was introduced but I couldn't figure out why it was added through the git history. It seems to have been around there since at least pip 0.6.

I'm pretty sure I can implement a Provider to preserve the behavior that it's asking for. I'm actually wondering if this option is in fact relevant once a resolver is added?

@pradyunsg pradyunsg added the type: maintenance Related to Development and Maintenance Processes label Mar 1, 2018
@pradyunsg
Copy link
Member Author

/ping @pfmoore @dstufft @xavfernandez

@pfmoore
Copy link
Member

pfmoore commented Mar 1, 2018

Not sure what you're asking. Why does --ignore-installed exist? I don't know the original reason, but I'm pretty sure I've used it to force-install a particular version (without having to first uninstall then reinstall, and no, I don't know why I needed --ignore-installed rather than --force-reinstall). I'm not too worried about having the specific option, but I'd rather we didn't lose the functionality. Of course step 1 is understanding what --ignore-installed does that none of the plethora of other similar options (--force-reinstall, --upgrade-strategy, ...) do. I'm not sure I can help with that 😕

When the new resolver comes in, I think it would be useful to have some use case directed documentation covering how to handle various common scenarios, rather than just a list of options that we leave people to combine as best they can.

@pradyunsg
Copy link
Member Author

Basically, I'm going through "figure out the option mess" phase, so, the situation you describe is exactly what I'm trying to break down and simplify. I guess if nothing else, good documentation sounds like a good idea.

The motivation being that every subtly different behaviour should have a separate class, which means a lot of subtly different behaviours would result in a lot of code. I guess the only way to figure out what to do here is to actually spend time going through everything.

@pfmoore
Copy link
Member

pfmoore commented Mar 2, 2018

Ah, OK. I think --force-reinstall is typically better, as it does a clean uninstall. As I understand it, --ignore-installed is bad because it simply installs over an existing installation, so it won't do a clean uninstall.

So I think the only use cases I see for --ignore-installed is to handle broken installations where metadata is corrupt or something, so that pip can't uninstall an existing version. (It might also be important in the context of --target, where the target directory isn't in site-packages - uninstall metadata might not be visible in that case).

@benoit-pierre
Copy link
Member

benoit-pierre commented Mar 2, 2018

I don't think there's a valid use case for --ignore-installed, it's way too easy to end up with a mess when using it. Better for users to uninstall manually, then to blindly execute such commands.

@mattficke
Copy link

When the new resolver comes in, I think it would be useful to have some use case directed documentation covering how to handle various common scenarios, rather than just a list of options that we leave people to combine as best they can.

Combining ignore-installed with other options (like force-reinstall) can lead to unexpected behavior, additional guidelines about usage would be helpful. Just opened a feature request ticket about disallowing invalid combinations: #9317

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: maintenance Related to Development and Maintenance Processes
Projects
None yet
Development

No branches or pull requests

4 participants