/ pip Public

# Temporarily restore --build-dir for PyCharm#9193

Closed
opened this issue Dec 1, 2020 · 43 comments · Fixed by #9198
Closed

# Temporarily restore --build-dir for PyCharm #9193

opened this issue Dec 1, 2020 · 43 comments · Fixed by #9198
Labels
type: feature request Request for a new feature
Milestone

### sfelixkim commented Dec 1, 2020 • edited

 Environment pip version: 20.3 Python version: 3.8 OS: Windows 10 Description Cannot install any packages when using PyCharm python interpreter. The virtual environment is created using virtualenv. No problem when executing pip install [package] on either PyCharm terminal or cmd prompt directly. Problem resolved when pip is downgraded to 20.2 (had to be done on terminal by pip install pip==20.2.4) Expected behavior Install packages successfully. How to Reproduce create a new project on PyCharm (then the installed pip version is 20.3) install any package (e.g. flask) by typing the name and click the "Install Package" button An error occurs. Output executed command: pip install Flask  Error occurred: Non-zero exit code (2)  proposed solution: Try to run this command from the system terminal. Make sure that you use the correct version of 'pip' installed for your Python interpreter located at 'C:\path\to\project\folder\venv\Scripts\python.exe'.  command output: Usage: C:\path\to\project\folder\venv\Scripts\python.exe -m pip install [options] [package-index-options] ... C:\path\to\project\folder\venv\Scripts\python.exe -m pip install [options] -r [package-index-options] ... C:\path\to\project\folder\venv\Scripts\python.exe -m pip install [options] [-e] ... C:\path\to\project\folder\venv\Scripts\python.exe -m pip install [options] [-e] ... C:\path\to\project\folder\venv\Scripts\python.exe -m pip install [options] ... no such option: --build-dir  The text was updated successfully, but these errors were encountered:

### uranusjr commented Dec 1, 2020

 @pradyunsg Would it be a good idea to restore the option before PyCharm can release a fix on their end?

changed the title Can't install packages with pip 20.3 via PyCharm Temporarily restore --build-dir for PyCharm Dec 1, 2020
added the type: feature request Request for a new feature label Dec 1, 2020

### gaborbernat commented Dec 1, 2020

 Do we know why PyCharm developers did not see the warning about that option being deprecated? Maybe we should improve on that.

### jerryvurbl commented Dec 1, 2020 • edited

 so this is basically a pycharm issue? Is 6 months warning enough? Probably. Should this critical breaking change be coordinated between the biggest IDE's developers and the developers of the most important executable in the python ecosystem? Probably. Where do we go from here? We have to open a PyCharm issue?

### gaborbernat commented Dec 1, 2020 • edited

 Should this critical breaking change be coordinated between the biggest IDE's developers and the developers of the most important executable in the python ecosystem? Probably. All major IDE developers have access to the pip changelog. The pip developer team has no way to know what deprecated interfaces these IDEs use (against emitting warnings for 6+ months), especially sometimes when those sources are behind closed doors. Yes, you should be opening a PyCharm issue. The issue lies with them at the end of the day. Should they perhaps have a test suite against the master branch/RC versions of pip? Probably.

### sbidoul commented Dec 1, 2020

 Would it help if the option was still present as a no-op ?

### gaborbernat commented Dec 1, 2020 • edited

 The PyCharm issue https://youtrack.jetbrains.com/issue/PY-45712. Seems there was a commit to remove the deprecated flag yesterday on the PyCharm code base JetBrains/intellij-community@a618daa

### pfmoore commented Dec 1, 2020 • edited

 @sbidoul I was going to say yes, leaving the option as a no-op for a short while might be helpful. But if JetBrains have already committed the change, it sounds like they are in a position to release a fix, so I think we can leave it to them.

### pradyunsg commented Dec 1, 2020 • edited

 Should this critical breaking change be coordinated between the biggest IDE's developers and the developers of the most important executable in the python ecosystem? Ok, this annoys me more than I should probably allow it to. pip's maintainers have communicated about this change across multiple public channels, (as noted earlier) this option has been printing warnings on every invocation for the past few releases and we even had a beta release for 20.3 out for nearly 1 month, where this option was removed. I'm genuinely not sure what more we could've done to avoid this situation from our end. From my perspective, no reports/requests came in related to this deprecation from end users, so this was supposed to be "the easy one" -- I'd even dropped it from our 20.3 release announcement publicity push, because I thought: well, this removal seemed to affect no one so why call it out in the emails (LOL). To imply that pip's devs didn't do enough feels exceedingly dismissive of our efforts, and is the kind of thing that results in folks walking away from projects. sigh Sorry, I got worked up there. @pradyunsg Would it be a good idea to restore the option before PyCharm can release a fix on their end? Yes. It seems like PyCharm has been able to make the changes on their end to accomodate for the removal, but I'd imagine it might still be necessary to reduce breakage as they roll out the fix. If someone from the PyCharm team could clarify/provide an answer to the question: Would it help if the option was still present as a no-op ? I don't want to reintroduce the --build-dir functionality to be very honest -- that removal was blocking internal cleanups I'd really like to get to -- but maintaining a no-op option for a few releases is very "cheap" in terms of maintenance effort. Looking at the removal patch, it seems like this would be OK? I'm happy to cut a pip 20.3.1 later today (assuming someone can file a PR adding this, with a comment pointing back to this issue), if that would help with this breakage for PyCharm's users.

### pfmoore commented Dec 1, 2020

 To imply that pip's devs didn't do enough feels exceedingly dismissive of our efforts, and is the kind of thing that results in folks walking away from projects. Agreed. Can I also note that the comments I saw from the PyCharm developers were polite, reasonable, and not at all confrontational, so I'd like to publicly thank them for taking a completely reasonable approach here. Drive-by criticism of either project over this from 3rd-party bystanders is neither helpful nor welcome, in my view.

### jerryvurbl commented Dec 1, 2020 via email

 Fair enough, will do. That said maybe this should have been a semver major release change on the pip side? it should be noted that a user has to adopt this pip change to break things and it can be rolled back in the same way. maybe its me but i dont read all the release notes for the hundreds of projects i use and track but a major release increment usually gets for attention. a breaking change appearing between x.2.4 to x.3.0 seems to violate this seemingly basic heads up but i didnt review this issue close enough to know that my assertion here is correct. if it is i dont know what semver is for anymore. apologies if this seems strident i dont mean it to be. i had some intensive rollbacks i had to do where i was used to trusting these upgrades without doubt. anyway, its mostly a pycharm issue i agree but a breaking change is a breaking change. my limited perspective says that the built in warning systems did not work. … On Dec 1, 2020, 2:14 AM -0800, Bernát Gábor ***@***.***>, wrote: > Should this critical breaking change be coordinated between the biggest IDE's developers and the developers of the most important executable in the python ecosystem? Probably. All major IDE developers have access to the pip changelog. The pip developer team has no way to know what deprecated interfaces these IDEs use (against emitting warnings for 6+ months), especially sometimes when those sources are behind closed doors. Yes, you should be opening a PyCharm issue. The issue lies with them at the end of the day. Should they perhaps have a test suite against the master branch of pip? Probably. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

### gaborbernat commented Dec 1, 2020 • edited

 That said maybe this should have been a semver major release change on the pip side? If you take a look at pip version number (2020.4) you'll notice that's a fairly big number. It's because pip does not use semantic versioning but instead https://calver.org/overview.html. As such there's no concept of major release you might be familiar with semver. it should be noted that a user has to adopt this pip change to break things and it can be rolled back in the same way. The warning message printed on every invocation for the last few months (at least) should suffice as a notification of you're doing something wrong. Please familiarize yourself with it https://calver.org/overview.html#when-to-use-calver 👍

### pradyunsg commented Dec 1, 2020 • edited

 That said maybe this should have been a semver major release change on the pip side? If we followed Semver -- sure, it would've been -- but we don't, for a lot of reasons that I won't go into. I'll flag that pip has been one of the most prominent projects using CalVar for over 2 years now. We also have a documented deprecation policy about making breaking changes: https://pip.pypa.io/en/stable/development/release-process/#deprecation-policy my limited perspective says that the built in warning systems did not work. This is definitely true. I do want us to identify why this happened, so that we can avoid this class of issues in the future. I say that we let this thread be "at rest" now, until tomorrow or until one of the PyCharm developers responds here. :)

### east825 commented Dec 1, 2020

 Hi everyone! I'm from a PyCharm team. We didn't notice the deprecation because this option was used only in an internal script that we normally don't launch manually. We can definitely improve in this regard by reporting any deprecation messages from the tool to stderr, at least in the internal/EAP mode as an early diagnostic, so that it doesn't happen again. As for why we needed --build-dir in the first place, it seems that now it's more of a historical artifact back from the days when pip didn't build binary packages in TMP by default, so we had to emulate this behavior (creating a temporary directory, building in it and then removing) manually. Unfortunately, the history is somewhat scarce, and the option was added in 2013. Can someone shed the light on what was the former behavior, so that we were entirely sure that by removing the option we don't break some corner cases? In the distutils-sig thread that I started Tzu-ping Chung has already mentioned that this behavior changed around pip 6.x. Is it accurate? Would you mind pointing me to the corresponding changelog items? Making --build-dir a no-op for a little while, until we prepare updates to already released versions of PyCharm, especially if we really don't need it any longer, sounds just perfect.

### mgedmin commented Dec 1, 2020

 A modest proposal: if you add a time.sleep() after printing the deprecation warning, people will start investigating why pip is suddenly slow and will notice the warning. For best results increase the delay with every subsequent release.

### gaborbernat commented Dec 1, 2020

 For best results increase the delay with every subsequent release. This can be interpreted as one of those passive-aggressive interactions 🤔 What about people who can't upgrade and pin, should they be penalized?

### brainwane commented Dec 1, 2020

 @mgedmin I presume that your phrase "modest proposal" was meant to mark your comment as satirical, and not to be taken seriously. Am I correct? [Also, @east825, thank you & thanks to PyCharm for sponsoring the Python Software Foundation and helping financially contribute to the infrastructure of Python!]

### east825 commented Dec 1, 2020

 @brainwane I've passed unexpected, but heart-warming praises to the team :)

### east825 commented Dec 1, 2020 • edited

 @pradyunsg Would it be possible to keep the dummy no-op option for another 6 months (maybe even hiding it in the --help output)? We'd like to ensure that most of the users of 2020.x releases managed to upgrade to the patched versions of the IDEs. I realize that it's not at all "a little while", but it would help us a lot with a smooth transition.

### sbidoul commented Dec 1, 2020

 @pradyunsg @east825 I'll do the PR within the next hours.

added a commit to sbidoul/pip that referenced this issue Dec 1, 2020
 Restore --build-dir 
 8ad7ac4 
Closes pypa#9193
mentioned this issue Dec 1, 2020

### pradyunsg commented Dec 1, 2020

 Would it be possible to keep the dummy no-op option for another 6 months (maybe even hiding it in the --help output)? We'd like to ensure that most of the users of 2020.x releases managed to upgrade to the patched versions of the IDEs. Yes, I'm 100% on board for doing this. I'm pretty sure that no one in @pypa/pip-committers would be opposed to this, but, if they are, I'd imagine we'll hear from them here. ;) @sbidoul wheee! Thanks! :)

added a commit to sbidoul/pip that referenced this issue Dec 1, 2020
 Restore --build-dir 
 ce5cb81 
Closes pypa#9193

### sbidoul commented Dec 1, 2020

 There you go: #9198.

### pradyunsg commented Dec 1, 2020

 FYI folks - I plan to keep this issue open, until the re-removal of the option in 2021. That way we can cross check before 21.1 that PyCharm folks have been able to successfully transition most of their users.

### KernelBypass commented Dec 2, 2020

 Can this error break venv setup in any way?

### east825 commented Dec 2, 2020

 @SergeiBond It can interfere, if you're automatically installing a package in it, e.g. Django or Flask, through a new project wizard. An empty virtual environment is still created in this case, though.

### sfelixkim commented Dec 2, 2020

 It looks like the new release of PyCharm (2020.2.5) got it fixed? PyCharm people, please confirm :)

### east825 commented Dec 2, 2020

 @sfelixkim Correct! 2020.2.5 was released specifically because of this fix. It's also included in 2020.1.5 and the upcoming 2020.3.

### pradyunsg commented Dec 2, 2020

 I'll cut a release in my lunch break today. :)

### east825 commented Dec 2, 2020

 First of all, huge thanks to everyone involved in addressing this problem so promptly! I don't want to be a pain in the neck, but, nonetheless, can someone please still elaborate a bit on how the behavior of install with and without --build-dir has changed over the course of the years, so that the option has become effectively redundant and it was decided to drop it altogether?

### pradyunsg commented Dec 2, 2020

 I'm not a 100% sure on the history, but based on what you described earlier, yes, it's redundant for PyCharm's use case now. :) I've listed what seem to be the changelog entries relevant to this option (from https://pip.pypa.io/en/latest/news/). Folks can Ctrl+F to figure out the timeline and all that. :) Deprecate -b/--build/--build-dir/--build-directory. Its current behaviour is confusing and breaks in case different versions of the same distribution need to be built during the resolution process. Using the TMPDIR/TEMP/TMP environment variable, possibly combined with --no-clean covers known use cases. () Use a randomized and secure default build directory when possible. (, , , , CVE-2014-8991) DEPRECATION pip install --build and pip install --no-clean are now NOT deprecated. This reverses the deprecation that occurred in v1.5.3. () DEPRECATION pip install --build and pip install --no-clean are now deprecated. () Added documentation on usage of --build command line option ()

### vurbl commented Dec 3, 2020

 To imply that pip's devs didn't do enough feels exceedingly dismissive of our efforts, and is the kind of thing that results in folks walking away from projects. Agreed. Can I also note that the comments I saw from the PyCharm developers were polite, reasonable, and not at all confrontational, so I'd like to publicly thank them for taking a completely reasonable approach here. Drive-by criticism of either project over this from 3rd-party bystanders is neither helpful nor welcome, in my view. Apologies, thanks for the vigorous response. Truly appreciated.

mentioned this issue Dec 3, 2020
added this to the 21.1 milestone Dec 3, 2020

### uranusjr commented Dec 3, 2020

 I took the liberty to create the 21.1 milestone add this to it.

### pradyunsg commented Dec 3, 2020

 Thanks @uranusjr! FWIW, 20.3.1 is out with the requested fix.

### KernelBypass commented Dec 3, 2020

 @SergeiBond It can interfere, if you're automatically installing a package in it, e.g. Django or Flask, through a new project wizard. An empty virtual environment is still created in this case, though. Hmm, weird: I got this error when I was actually starting a new Flask project with venv. However, everything seems to be working fine despite the error. It seems that Flask package got installed just fine.

### east825 commented Dec 3, 2020

 @pradyunsg Thanks a lot for the excerpt from the changelog. Apparently, #2122 is just what I was looking for. Shame on me, somehow I couldn't find it myself right away. All in all, the option indeed seems long overdue for removal from our scripts.

mentioned this issue Dec 3, 2020
bot added a commit to duckinator/emanate that referenced this issue Dec 4, 2020
 Merge #194 #197 
 4344bf2 
194: Update pytest-pylint to 0.18.0 r=duckinator a=pyup-bot

This PR updates [pytest-pylint](https://pypi.org/project/pytest-pylint) from **0.17.0** to **0.18.0**.

*The bot wasn't able to find a changelog for this release. [Got an idea?](https://github.com/pyupio/changelogs/issues/new)*

<details>

- PyPI: https://pypi.org/project/pytest-pylint
- Changelog: https://pyup.io/changelogs/pytest-pylint/
- Repo: https://github.com/carsongee/pytest-pylint
</details>

197: Update pip to 20.3.1 r=duckinator a=pyup-bot

This PR updates [pip](https://pypi.org/project/pip) from **20.2.4** to **20.3.1**.

<details>
<summary>Changelog</summary>

### 20.3.1

===================

Deprecations and Removals
-------------------------

- The --build-dir option has been restored as a no-op, to soften the transition
for tools that still used it. (9193 &lt;https://github.com/pypa/pip/issues/9193&gt;_)


### 20.3

- Introduce a new ResolutionImpossible error, raised when pip encounters un-satisfiable dependency conflicts (8546 &lt;https://github.com/pypa/pip/issues/8546&gt;_, 8377 &lt;https://github.com/pypa/pip/issues/8377&gt;_)
- Add a subcommand debug to pip config to list available configuration sources and the key-value pairs defined in them. (6741 &lt;https://github.com/pypa/pip/issues/6741&gt;_)
- Warn if index pages have unexpected content-type (6754 &lt;https://github.com/pypa/pip/issues/6754&gt;_)
- Allow specifying --prefer-binary option in a requirements file (7693 &lt;https://github.com/pypa/pip/issues/7693&gt;_)
- Generate PEP 376 REQUESTED metadata for user supplied requirements installed
by pip. (7811 &lt;https://github.com/pypa/pip/issues/7811&gt;_)
- Warn if package url is a vcs or an archive url with invalid scheme (8128 &lt;https://github.com/pypa/pip/issues/8128&gt;_)
- Parallelize network operations in pip list. (8504 &lt;https://github.com/pypa/pip/issues/8504&gt;_)
- Allow the new resolver to obtain dependency information through wheels
invoke pip with --use-feature=fast-deps. (8588 &lt;https://github.com/pypa/pip/issues/8588&gt;_)
- Support --use-feature in requirements files (8601 &lt;https://github.com/pypa/pip/issues/8601&gt;_)

Bug Fixes
---------

- Use canonical package names while looking up already installed packages. (5021 &lt;https://github.com/pypa/pip/issues/5021&gt;_)
- Fix normalizing path on Windows when installing package on another logical disk. (7625 &lt;https://github.com/pypa/pip/issues/7625&gt;_)
- The VCS commands run by pip as subprocesses don&#39;t merge stdout and stderr anymore, improving the output parsing by subsequent commands. (7968 &lt;https://github.com/pypa/pip/issues/7968&gt;_)
- Correctly treat non-ASCII entry point declarations in wheels so they can be
installed on Windows. (8342 &lt;https://github.com/pypa/pip/issues/8342&gt;_)
- Update author email in config and tests to reflect decommissioning of pypa-dev list. (8454 &lt;https://github.com/pypa/pip/issues/8454&gt;_)
- Headers provided by wheels in .data directories are now correctly installed
into the user-provided locations, such as --prefix, instead of the virtual
environment pip is running in. (8521 &lt;https://github.com/pypa/pip/issues/8521&gt;_)

Vendored Libraries
------------------

- Vendored htmlib5 no longer imports deprecated xml.etree.cElementTree on Python 3.

Improved Documentation
----------------------

- Add --no-input option to pip docs (7688 &lt;https://github.com/pypa/pip/issues/7688&gt;_)
- List of options supported in requirements file are extracted from source of truth,
instead of being maintained manually. (7908 &lt;https://github.com/pypa/pip/issues/7908&gt;_)
- Fix pip config docstring so that the subcommands render correctly in the docs (8072 &lt;https://github.com/pypa/pip/issues/8072&gt;_)
- replace links to the old pypa-dev mailing list with https://mail.python.org/mailman3/lists/distutils-sig.python.org/ (8353 &lt;https://github.com/pypa/pip/issues/8353&gt;_)
- Fix example for defining multiple values for options which support them (8373 &lt;https://github.com/pypa/pip/issues/8373&gt;_)
- Add documentation for the ResolutionImpossible error that helps the user fix dependency conflicts (8459 &lt;https://github.com/pypa/pip/issues/8459&gt;_)
- Add feature flags to docs (8512 &lt;https://github.com/pypa/pip/issues/8512&gt;_)
- Document how to install package extras from git branch and source distributions. (8576 &lt;https://github.com/pypa/pip/issues/8576&gt;_)


### 20.3b1

===================

Deprecations and Removals
-------------------------

- pip freeze will stop filtering the pip, setuptools, distribute and wheel packages from pip freeze output in a future version.
To keep the previous behavior, users should use the new --exclude option. (4256 &lt;https://github.com/pypa/pip/issues/4256&gt;_)
- Deprecate support for Python 3.5 (8181 &lt;https://github.com/pypa/pip/issues/8181&gt;_)
- Document that certain removals can be fast tracked. (8417 &lt;https://github.com/pypa/pip/issues/8417&gt;_)
- Document that Python versions are generally supported until PyPI usage falls below 5%. (8927 &lt;https://github.com/pypa/pip/issues/8927&gt;_)
- Deprecate --find-links option in pip freeze (9069 &lt;https://github.com/pypa/pip/issues/9069&gt;_)

Features
--------

- Add --exclude option to pip freeze and pip list commands to explicitly exclude packages from the output. (4256 &lt;https://github.com/pypa/pip/issues/4256&gt;_)
- Allow multiple values for --abi and --platform. (6121 &lt;https://github.com/pypa/pip/issues/6121&gt;_)
- Add option --format to subcommand list of pip  cache, with abspath choice to output the full path of a wheel file. (8355 &lt;https://github.com/pypa/pip/issues/8355&gt;_)
- Improve error message friendliness when an environment has packages with
corrupted metadata. (8676 &lt;https://github.com/pypa/pip/issues/8676&gt;_)
- Make the setup.py install deprecation warning less noisy. We warn only
when setup.py install succeeded and setup.py bdist_wheel failed, as
situations where both fails are most probably irrelevant to this deprecation. (8752 &lt;https://github.com/pypa/pip/issues/8752&gt;_)
fetching metadata when the fast-deps feature is used with
pip wheel and pip download. (8804 &lt;https://github.com/pypa/pip/issues/8804&gt;_)
- When installing a git URL that refers to a commit that is not available locally
after git clone, attempt to fetch it from the remote. (8815 &lt;https://github.com/pypa/pip/issues/8815&gt;_)
- Include http subdirectory in pip cache info and pip cache purge commands. (8892 &lt;https://github.com/pypa/pip/issues/8892&gt;_)
- Cache package listings on index packages so they are guarenteed to stay stable
during a pip command session. This also improves performance when a index page
is accessed multiple times during the command session. (8905 &lt;https://github.com/pypa/pip/issues/8905&gt;_)
- New resolver: Tweak resolution logic to improve user experience when
user-supplied requirements conflict. (8924 &lt;https://github.com/pypa/pip/issues/8924&gt;_)
- Support Python 3.9. (8971 &lt;https://github.com/pypa/pip/issues/8971&gt;_)
- Log an informational message when backtracking takes multiple rounds on a specific package. (8975 &lt;https://github.com/pypa/pip/issues/8975&gt;_)
- Switch to the new dependency resolver by default. (9019 &lt;https://github.com/pypa/pip/issues/9019&gt;_)
- Remove the --build-dir option, as per the deprecation. (9049 &lt;https://github.com/pypa/pip/issues/9049&gt;_)

Bug Fixes
---------

- Propagate --extra-index-url from requirements file properly to session auth,
so that keyring auth will work as expected. (8103 &lt;https://github.com/pypa/pip/issues/8103&gt;_)
- Allow specifying verbosity and quiet level via configuration files
and environment variables. Previously these options were treated as
boolean values when read from there while through CLI the level can be
specified. (8578 &lt;https://github.com/pypa/pip/issues/8578&gt;_)
- Only converts Windows path to unicode on Python 2 to avoid regressions when a
POSIX environment does not configure the file system encoding correctly. (8658 &lt;https://github.com/pypa/pip/issues/8658&gt;_)
- List downloaded distributions before exiting pip download
when using the new resolver to make the behavior the same as
that on the legacy resolver. (8696 &lt;https://github.com/pypa/pip/issues/8696&gt;_)
- New resolver: Pick up hash declarations in constraints files and use them to
filter available distributions. (8792 &lt;https://github.com/pypa/pip/issues/8792&gt;_)
- Avoid polluting the destination directory by resolution artifacts
when the new resolver is used for pip download or pip wheel. (8827 &lt;https://github.com/pypa/pip/issues/8827&gt;_)
- New resolver: If a package appears multiple times in user specification with
different --hash options, only hashes that present in all specifications
should be allowed. (8839 &lt;https://github.com/pypa/pip/issues/8839&gt;_)
- Tweak the output during dependency resolution in the new resolver. (8861 &lt;https://github.com/pypa/pip/issues/8861&gt;_)
- Correctly search for installed distributions in new resolver logic in order
to not miss packages (virtualenv packages from system-wide-packages for example) (8963 &lt;https://github.com/pypa/pip/issues/8963&gt;_)
- Do not fail in pip freeze when encountering a direct_url.json metadata file
with editable=True. Render it as a non-editable file:// URL until modern
editable installs are standardized and supported. (8996 &lt;https://github.com/pypa/pip/issues/8996&gt;_)

Vendored Libraries
------------------

- Fix devendoring instructions to explicitly state that vendor.txt should not be removed.
It is mandatory for pip debug command.

Improved Documentation
----------------------

- Add documentation for &#39;.netrc&#39; support. (7231 &lt;https://github.com/pypa/pip/issues/7231&gt;_)
- Add OS tabs for OS-specific commands. (7311 &lt;https://github.com/pypa/pip/issues/7311&gt;_)
- Add note and example on keyring support for index basic-auth (8636 &lt;https://github.com/pypa/pip/issues/8636&gt;_)
- Added initial UX feedback widgets to docs. (8783 &lt;https://github.com/pypa/pip/issues/8783&gt;_, 8848 &lt;https://github.com/pypa/pip/issues/8848&gt;_)
- Add ux documentation (8807 &lt;https://github.com/pypa/pip/issues/8807&gt;_)
- Update user docs to reflect new resolver as default in 20.3. (9044 &lt;https://github.com/pypa/pip/issues/9044&gt;_)
- Improve migration guide to reflect changes in new resolver behavior. (9056 &lt;https://github.com/pypa/pip/issues/9056&gt;_)


</details>

<details>

- PyPI: https://pypi.org/project/pip
- Changelog: https://pyup.io/changelogs/pip/
- Homepage: https://pip.pypa.io/
</details>

Co-authored-by: pyup-bot <github-bot@pyup.io>
Co-authored-by: Ellen Marie Dash <me@duckie.co>

### uranusjr commented Apr 3, 2021

 I… forgot what we should do for 21.2. Does anyone here still remember the context?

### sbidoul commented Apr 3, 2021

 I think we just need to remove the --build-dir option that is a no-op. That said, it has no maintenance costs so I'd be inclined to leave it in for a few more releases.

### pradyunsg commented Apr 3, 2021

 The change necessary here is to revert #9198. Happy to defer this to the next release too. :)

### uranusjr commented Apr 3, 2021

 Let’s leave this for the 21.1 RM to decide.

### sbidoul commented Apr 17, 2021

 This has been moved to 21.3 in #9783. Changing the milestone.

modified the milestones: 21.1, 21.3 Apr 17, 2021
mentioned this issue Sep 18, 2021

### pradyunsg commented Sep 18, 2021 • edited

 And, there's now a PR for removing this option. @east825 Do you know if there's any reason to not go forward with the migration plan from 6 months ago (i.e. removing the no-op flag now)?

### east825 commented Sep 20, 2021

 @pradyunsg I think it's completely fine to drop it now, go ahead. Thanks for keeping it for us for that long.

### pradyunsg commented Sep 21, 2021

 Awesome. Thanks for confirming! :)

### pradyunsg commented Oct 6, 2021

 Done in #10485.

mentioned this issue Oct 12, 2021