If I do something like `pytest tests/integration/test_cli.py`, something
about the ordering of imports means that `pipenv.environments` gets
loaded *before* `pytest_sessionstart` runs, which means that
`pipenv.environments.PIPENV_IS_CI` ends up false.
This adds and documents a workaround for
https://github.com/pypa/pipenv/issues/4909. It feels a bit weird to
pretend to be CI just to run the test suite, though. Maybe we can do
something about that later.
I ran into a lot of trouble trying to get the tests to run when working
on https://github.com/pypa/pipenv/pull/4908, and that was largely
because the instructions in this CONTRIBUTING.md file seem to have
rotted.
1. The bit about "can be run very simply" is bogus. It's
unfortunately not that simple right now.
2. `make test` (the docker approach) fails for me with this error:
```bash
$ make test
docker-compose up
[+] Running 1/0
⠿ Container pipenv-pipenv-tests-1 Recreated 0.1s
Attaching to pipenv-pipenv-tests-1
pipenv-pipenv-tests-1 | Collecting certifi
pipenv-pipenv-tests-1 | Downloading https://files.pythonhosted.org/packages/37/45/946c02767aabb873146011e665728b680884cd8fe70dde973c640e45b775/certifi-2021.10.8-py2.py3-none-any.whl (149kB)
pipenv-pipenv-tests-1 | Installing collected packages: certifi
pipenv-pipenv-tests-1 | Successfully installed certifi-2021.10.8
pipenv-pipenv-tests-1 | Path: /root/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
pipenv-pipenv-tests-1 | Installing Pipenv...
pipenv-pipenv-tests-1 | Obtaining file:///pipenv
pipenv-pipenv-tests-1 | Complete output from command python setup.py egg_info:
pipenv-pipenv-tests-1 | Traceback (most recent call last):
pipenv-pipenv-tests-1 | File "<string>", line 1, in <module>
pipenv-pipenv-tests-1 | File "/pipenv/setup.py", line 55
pipenv-pipenv-tests-1 | print(f"\033[1m{s}\033[0m")
pipenv-pipenv-tests-1 | ^
pipenv-pipenv-tests-1 | SyntaxError: invalid syntax
pipenv-pipenv-tests-1 |
pipenv-pipenv-tests-1 | ----------------------------------------
pipenv-pipenv-tests-1 | Command "python setup.py egg_info" failed with error code 1 in /pipenv/
pipenv-pipenv-tests-1 exited with code 1
```
The docker image it relies upon
(https://hub.docker.com/r/kennethreitz/pipenv-tests) hasn't been
updated in 4 years, so I assume it's just not something people use
anymore?
3. Relatedly, there was a `Dockerfile` at the root of this repo that
appears to be unused. Let me know if it's used somewhere I'm not
realizing, I can add it back!
4. https://kennethreitz.org/essays/be-cordial-or-be-on-your-way seems to
be a broken link now. I found
https://kennethreitz.org/essays/2013/01/27/be-cordial-or-be-on-your-way
on Google.
5. `./run-tests.sh` doesn't work for me. It's failing for the same
reason described by @ncoghlan here:
https://github.com/pypa/pip/issues/7953#issuecomment-611928262. He
said something about a `PIPENV_BOOTSTRAP` environment variable, but I
can't find any information about that.
Previously, due to default behavior of ArgumentParser, global --index-url,
--extra-index-url, and --trusted-host options in requirements files could be
abbreviated (e.g. "--index" == "--index-url"). As a result, unexpected
behavior could occur during processing of a requirements file with these
shortened option names when using Pipenv, which could be exploited by a
malicious actor to surreptitiously insert pip options using non-obvious
abbreviations.
For example, adding a line with "--t example.com" to the
requirements file would cause Pipenv to treat example.com as trusted, even
when example.com presents an invalid TLS certificate.
This commit disables support for abbreviated options in the ArgumentParser,
to align Pipenv's behavior when parsing global options in a requirements
file with the behavior in pip, as expected.
Frost Ming