Repository: jazzband/pip-tools

Issue:
Error importing BAR_TYPES with new pip 22.1 release
<!-- Describe the issue briefly here. -->
pip-tools breaks with the new version of pip "22.1". Error:

```
ImportError: cannot import name 'BAR_TYPES' from 'pip._internal.cli.progress_bars' (/tmp/tmpxfal9pqx/6297f3abdc8a9aff/test-env/lib/python3.9/site-packages/pip/_internal/cli/progress_bars.py)
```

#### Environment Versions

OS: Ubuntu 20.04
Python version: 3.9
pip version: 22.1
pip-tools version: 6.6.0

#### Steps to replicate

1. pip install -U pip pip-tools
2. pip-compile requirements.in

#### Expected result

Compilation is successful

#### Actual result

Full traceback from my CI job.
```
Traceback (most recent call last):
  File "/tmp/tmpxfal9pqx/6297f3abdc8a9aff/test-env/bin/pip-compile", line 5, in <module>
    from piptools.scripts.compile import cli
  File "/tmp/tmpxfal9pqx/6297f3abdc8a9aff/test-env/lib/python3.9/site-packages/piptools/scripts/compile.py", line 21, in <module>
    from ..repositories import LocalRequirementsRepository, PyPIRepository
  File "/tmp/tmpxfal9pqx/6297f3abdc8a9aff/test-env/lib/python3.9/site-packages/piptools/repositories/__init__.py", line 1, in <module>
    from .local import LocalRequirementsRepository
  File "/tmp/tmpxfal9pqx/6297f3abdc8a9aff/test-env/lib/python3.9/site-packages/piptools/repositories/local.py", line 14, in <module>
    from .pypi import PyPIRepository
  File "/tmp/tmpxfal9pqx/6297f3abdc8a9aff/test-env/lib/python3.9/site-packages/piptools/repositories/pypi.py", line 23, in <module>
    from pip._internal.cli.progress_bars import BAR_TYPES
ImportError: cannot import name 'BAR_TYPES' from 'pip._internal.cli.progress_bars' (/tmp/tmpxfal9pqx/6297f3abdc8a9aff/test-env/lib/python3.9/site-packages/pip/_internal/cli/progress_bars.py)
```


Discussion:
Looks like `BAR_TYPES` was removed in [this commit](https://github.com/pypa/pip/commit/728e4fe7c4168f62b8f47721aa56576cce5e46fb).
There's a fix for this in the new resolver PR, and we either need pull that bit out for a more immediate release, or finalize and merge that PR, which still has at least one problem. 
Just hit this in our CI
Pulling that out into a more immediate release seems reasonable to me. :)
For now i am just pinning `pip` to 22.0.4. Looking forward to the fix!
I can't be at a computer for a little while, @atugushev want to do a small release soon? 
IIRC this isn't the first time a new pip release has broken pip-tools. Would it be a good idea to have upper bounds in its dependency?
That commit has been in the pip main branch for a month. ideally, this repo should be testing against that regularly to catch for this kind of thing early, rather than needing to add a version cap that would just get in the way later.

oh dear, it *does* regularly check for this: https://github.com/jazzband/pip-tools/runs/6267937837?check_suite_focus=true

edit: oh yeah, here's where the relevant discussion continues, back through this wormhole to January: https://github.com/jazzband/pip-tools/issues/1558#issuecomment-1026462006
I'm a bit puzzled why pip and pip-tools are not kept within the same project.

pip-tools is instrumental to using pip since pip-compiles enables devs to separate direct dependencies from indirect ones. Also, it is great for fixing versions. 
(it makes the pip system work just like packages.json and npm...)
> I'm a bit puzzled why pip and pip-tools are not kept within the same project.

This also came up the last quarter, so I'll repeat https://github.com/jazzband/pip-tools/issues/1558#issuecomment-1026655582:

> I'm not sure whether a change in organisation would necessarily help, the pip team will continue to change their private internal functions as they need to (and there will be more changes to use Rich more for better output).

Also, the pip team are very busy working on pip and we can't expect them to maintain pip-tools as well.

In fact, moving pip-tools out of [Jazzband](https://jazzband.co) would be a backwards step: it would mean that _fewer_ people are able to maintain it.

---

As noted by @wizpig64 above, pip-tools does indeed have a daily cron regularly testing against pip's main branch, in fact it did catch the change in pip (but remember: pip has no official API) and started failing a month ago.

This also happened last quarter, so I'll also repeat https://github.com/jazzband/pip-tools/issues/1558#issuecomment-1026655582:

> Wherever it lives, I'd suggest a closer eye is paid to the integration of pip with pip-tools, especially in the lead up to pip's quarterly releases. (And look out for the pip release issues for planned release dates e.g. https://github.com/pypa/pip/issues/10726.)




Resolving patch:
diff --git a/piptools/repositories/pypi.py b/piptools/repositories/pypi.py
--- a/piptools/repositories/pypi.py
+++ b/piptools/repositories/pypi.py
@@ -20,7 +20,6 @@
 
 from click import progressbar
 from pip._internal.cache import WheelCache
-from pip._internal.cli.progress_bars import BAR_TYPES
 from pip._internal.commands import create_command
 from pip._internal.commands.install import InstallCommand
 from pip._internal.index.package_finder import PackageFinder
@@ -473,6 +472,9 @@ def _setup_logging(self) -> None:
             # refactored-out logging config.
             log.warning("Couldn't find a 'console' logging handler")
 
+        # This import will fail with pip 22.1, but here we're pip<22.0
+        from pip._internal.cli.progress_bars import BAR_TYPES
+
         # Sync pip's progress bars stream with LogContext.stream
         for bar_cls in itertools.chain(*BAR_TYPES.values()):
             bar_cls.file = log.stream


Test patch: