- Exclude python when searching virtualenvs created using nested
virtualenv interpreters (via `lib-dynload` library directory)
Signed-off-by: Dan Ryan <dan@danryan.co>
- Use `project.parsed_pipfile` to get all packages instead of a filtered
subset
- Determine index names via a new `refresh=True` argument to
`project.get_source()` which clears the current pipfile cache
- Fix parsing of requirement lines from direct URLs which were
previously excluding the `name@` portion and therefore generating
invalid links
Signed-off-by: Dan Ryan <dan@danryan.co>
- Resolve all VCS and non-piptools-resolveable deps in venv
- Implement pep517 for resolution of non-setuptools builds
- Add full support for the new dependency link format
- Fix breakages from pip 19* rollout and subsequent setuptools breakage
Signed-off-by: Dan Ryan <dan.ryan@xyleminc.com>
- Clean up test config and environment variable handling
- Unset env var changes performend by `pipenv run`
- Make `environments.is_in_virtualenv()` more dynamic -- read
environment on the fly
- Split up tests on `pipenv run` to reduce complexity -- one test for
global run (no virtualenv creation), one test for virtualenv creation
- Add `warn_in_virtualenv` call to `run` command, why doesn't click
invoke this automatically?
Signed-off-by: Dan Ryan <dan@danryan.co>
Carets introduce a difficult situation since they are essentially
"lossy" when parses. Consider this in cmd.exe:
> echo "foo^bar"
"foo^bar"
> echo foo^^bar
foo^bar
The two commands produce different results, but are both parsed by the
shell as `foo^bar`, and there's essentially no sensible way to tell what
was actually passed in. This implementation assumes the quoted variation
(the first) since it is easier to implement, and arguably the more common
case.
- Stop preferring resolution of VCS dependencies in all cases
- Resolve vcs dependencies together with non-vcs dependencies
- Clarify blocking and no-deps logic
- Add artifacts and tests
- Add vendoring task for artifacts
- Clean up release tasks
- Fixes#3296
Signed-off-by: Dan Ryan <dan@danryan.co>
Dan Ryan