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

Start warning on non compliant pyproject.toml files and rejecting incorrect ones #5512

Merged

Conversation

pradyunsg
Copy link
Member

@pradyunsg pradyunsg commented Jun 18, 2018

Related to #5416

PEP 518 states:

There will be a [build-system] table in the configuration file to store build-related data. Initially only one key of the table will be valid and mandatory: requires. That key will have a value of a list of strings...

This PR makes pip warn when installing packages that they do not define build-system.requires in their pyproject.toml files and error out when it's not a list of strings.

build_system = pp_toml.get('build-system', {})
if "requires" not in build_system:
raise InstallationError(
"{} does not comply with PEP 518 as it since it's "
Copy link
Member

Choose a reason for hiding this comment

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

as it since it's?

Copy link
Member

Choose a reason for hiding this comment

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

I'd use the same format for both messages:

raise InstallationError(
		"{} does not comply with PEP 518 as pyproject.toml does"
		"not contain a valid [build-system].requires entry: {}"
		.format(self, reason) # with reason: 'missing' or 'not a list of strings'
		)
```

Copy link
Member

Choose a reason for hiding this comment

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

Also, the function could be simplified to return the list of build requirements or None if PEP 518 support is not used, no need for the isolate return value anymore (and the corresponding code in prep_for_dist simplified too).

Copy link
Member Author

@pradyunsg pradyunsg Jun 18, 2018

Choose a reason for hiding this comment

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

Indeed. Let's simplify the error message logic and the function.

#!/usr/bin/env python
from setuptools import setup

import simplewheel # ensure dependency is installed
Copy link
Member

Choose a reason for hiding this comment

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

That's not necessary, no?

result = script.pip(
'install',
'-f', common_wheels,
'-f', data.find_links,
Copy link
Member

Choose a reason for hiding this comment

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

Those 2 -f arguments are unnecessary, no?

Copy link
Member Author

Choose a reason for hiding this comment

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

Indeed.

result = script.pip(
'install',
'-f', common_wheels,
'-f', data.find_links,
Copy link
Member

Choose a reason for hiding this comment

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

Same as above.

Copy link
Member

Choose a reason for hiding this comment

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

I'd factorize the 2 tests with @pytest.mark.parametrize.

Copy link
Member Author

Choose a reason for hiding this comment

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

Nice idea about factorizing the tests.


requires = build_system["requires"]
is_list_of_str = isinstance(requires, list) and all(
isinstance(req, str) for req in requires
Copy link
Member

Choose a reason for hiding this comment

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

-                isinstance(req, str) for req in requires
+                isinstance(req, six.string_types) for req in requires

@@ -571,8 +571,30 @@ def get_pep_518_info(self):
if os.path.isfile(self.pyproject_toml):
Copy link
Member

Choose a reason for hiding this comment

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

How about taking the opportunity to simplify the function by getting the non PEP 518 case out of the way first:

        if not os.path.isfile(self.pyproject_toml):
	    return (['setuptools', 'wheel'], False) 

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeps. Good idea.

@pradyunsg
Copy link
Member Author

Thanks for the review @benoit-pierre! Much appreciated. :)

@asottile
Copy link
Contributor

I really think the PEP should be amended. As it is right now:

someone innocently adds black / towncrier / $othertool information in newly created pyproject.toml and suddenly their package isn't installable

I think now that PEP518 has settled on toml + pyproject.toml a bunch of tools are going to switch from setup.cfg / tox.ini (which has various problems due to interpolation, etc.).

@RonnyPfannschmidt
Copy link
Contributor

this should be a big red warning for a while,
for example pytest ever since using towncrier is "invalid"

(this is on us as well for not properly researching the pep either)

but in the end just rejecting the projects will "break" what was "working"

i also disagree with @asottile wrt amending the pep - but pip will have to be graceful since it didnt reject before

@pradyunsg
Copy link
Member Author

@RonnyPfannschmidt I stated in #5402 (comment) why I think it's better to reject "working"; until the PEP can be updated.

@pradyunsg
Copy link
Member Author

@asottile The next step for amending the PEP would be to start a new thread on distutils-sig, making a case for why the amendment should be made.

@RonnyPfannschmidt
Copy link
Contributor

@pradyunsg this will break various versions of pytest at least as well as plenty of other packages then ^^

@pradyunsg
Copy link
Member Author

pradyunsg commented Jun 19, 2018

We're having a discussion about this in 3 places. Can we please move the discussion about dealing with non-compliant pyproject.toml files to #5416?

RonnyPfannschmidt added a commit to RonnyPfannschmidt/pytest that referenced this pull request Jun 19, 2018
this makes the file valid and prepares for pypa/pip#5416 and pypa/pip#5512
@pradyunsg pradyunsg changed the title Start refusing non compliant pyproject.toml files Start warning on non compliant pyproject.toml files and rejecting incorrect ones Jun 19, 2018
@pradyunsg pradyunsg force-pushed the feature/refuse-non-compliant-pyproject branch from ed154a1 to 2b68c79 Compare June 19, 2018 10:58
@blueyed
Copy link
Contributor

blueyed commented Jun 20, 2018

From my understanding PEP 518 only states that requires is required in the build-system section, but not that the build-system section is required.
And using the provided JSON schema allows for an empty pyproject.toml (i.e. "{}" as JSON).

@pradyunsg
Copy link
Member Author

@blueyed I read it differently; I think we're in distutils-sig territory now on this -- amending PEP 518 to remove this ambiguity.

@blueyed
Copy link
Contributor

blueyed commented Jun 20, 2018

@pradyunsg
Great (do you have link?) (misunderstood that there was discussion already somewhere happening).
Apart from that you can easily test it using the provided JSON schema already.

@pradyunsg
Copy link
Member Author

@pypa/pip-committers Are there any reservations/blockers to merging this?

  • The behavior change here is an improvement over status quo
  • Transitioning to either of the positions the PEP might take is straightforward:
    • optional: stop warning when it's missing
    • mandatory: error out when it's missing

@pfmoore
Copy link
Member

pfmoore commented Jun 20, 2018

@pradyunsg No reservations from me.

@lock
Copy link

lock bot commented Jun 2, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 2, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 2, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation PEP implementation Involves some PEP
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants