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

Set build_isolation and use_pep517 correctly #4248

Merged
merged 4 commits into from
May 11, 2020
Merged

Conversation

techalchemy
Copy link
Member

  • Fix how use_pep517 and build_isolation are read from the
    environment -- introduce a new environment helper to detect
    <PREFIX>_<SETTING> and <PREFIX>_NO_<SETTING>, check for booleans
    and return appropriately boolean, str, or None types
  • Check for False values when adding --no-use-pep517 and
    --no-build-isolation during resolution rather than falsey values
  • Change environment variable name from PIP_PYTHON_VERSION to
    PIPENV_REQUESTED_PYTHON_VERSION to avoid causing pip to fail due
    to accidentally percieving the python_version flag as being set --
    this is an artifact from attempting to resolve outside of the
    virtualenv
  • Add pipenv to the path of patched notpip.__main__ to accommodate
    updated import fully qualified module names
  • Update pip and piptools patches
  • Add test packages for each of two known failure modes: outdated
    setuptools with a missing build-backend (which pip forces to
    build_meta:__legacy__ & which doesn't exist before 40.8), and
    import Cython statements in setup.py in packages with properly
    defined pyproject.toml build-backend lines.
  • Fixes pipenv not honoring setup_requires while locking #4231
  • Replaces, includes, and closes Float wheels to the top of the candidate sort order #4242

- `ignore_compatibility` is meant to resolve hashes into the lockfile
  after resolution happens
- We still want compatible items to be the ones we actually tell pip to
  install
- Fixes #4231

Signed-off-by: Dan Ryan <dan.ryan@canonical.com>
@techalchemy techalchemy added Category: Dependency Resolution Issue relates to dependency resolution. Category: Tests Relates to tests. PR: awaiting-review The PR related to this issue is awaiting review by a maintainer. Priority: Critical This issue is critical and affects usability or core functionality. Type: Bugfix This issue provides a fix for a known bug. labels May 9, 2020
@techalchemy techalchemy added this to the April 2020 Release milestone May 9, 2020
- Fix how `use_pep517` and `build_isolation` are read from the
  environment -- introduce a new environment helper to detect
  `<PREFIX>_<SETTING>` and `<PREFIX>_NO_<SETTING>`, check for booleans
  and return appropriately boolean, str, or None types
- Check for `False` values when adding `--no-use-pep517` and
  `--no-build-isolation` during resolution rather than falsey values
- Change environment variable name from `PIP_PYTHON_VERSION` to
  `PIPENV_REQUESTED_PYTHON_VERSION` to avoid causing `pip` to fail due
  to accidentally percieving the `python_version` flag as being set --
  this is an artifact from attempting to resolve outside of the
  virtualenv
- Add `pipenv` to the path of patched `notpip.__main__` to accommodate
  updated import fully qualified module names
- Update `pip` and `piptools` patches
- Add test packages for each of two known failure modes: outdated
  `setuptools` with a missing `build-backend` (which `pip` forces to
  `build_meta:__legacy__` & which doesn't exist before `40.8`), and
  `import Cython` statements in `setup.py` in packages with properly
  defined `pyproject.toml` `build-backend` lines.
- Fixes #4231
- Replaces, includes, and closes #4242

Signed-off-by: Dan Ryan <dan.ryan@canonical.com>

Add integration tests for #4231

Signed-off-by: Dan Ryan <dan.ryan@canonical.com>
if positive_lookup in os.environ:
if _is_env_truthy(positive_lookup):
return bool(os.environ[positive_lookup])
return os.environ[positive_lookup]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems wrong to me. Think of ENABLE_SOMETHING=0, does it mean to enable or disable?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so the answer to that is it should be disabled -- the real answer is that I was not at all thinking about how _is_env_truthy works and it really can't be used here to achieve this

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, you are probably seeking for _is_env_boolean_like.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh gosh is that a thing, I couldn't think of the name of it and probably just reinvented it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not implemented, I just make up the name that indicates how the function should work.

Signed-off-by: Dan Ryan <dan.ryan@canonical.com>
Signed-off-by: Dan Ryan <dan.ryan@canonical.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Dependency Resolution Issue relates to dependency resolution. Category: Tests Relates to tests. PR: awaiting-review The PR related to this issue is awaiting review by a maintainer. Priority: Critical This issue is critical and affects usability or core functionality. Type: Bugfix This issue provides a fix for a known bug.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

pipenv not honoring setup_requires while locking
2 participants