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

Implement PEP 517 Build Backend #1039

Closed
wants to merge 19 commits into from
Closed

Implement PEP 517 Build Backend #1039

wants to merge 19 commits into from

Conversation

ghost
Copy link

@ghost ghost commented May 22, 2017

This complies with the pep that will probably be adopted in any case, and doesn't break any existing functionality.

@ghost
Copy link
Author

ghost commented May 22, 2017

@jaraco This should be okay to go if the tests pass. It's not bulletproof but pip can always fall back.

@jaraco
Copy link
Member

jaraco commented May 28, 2017

Can you provide a link to the pep? Why use py517 instead of pep517?

@ghost
Copy link
Author

ghost commented May 31, 2017

Wow, it looks like it's been accepted.

https://www.python.org/dev/peps/pep-0517/

@jaraco I'll rename the module. I think pip was originally going to have it's own setuptools backend but if we put the backend in the setuptools repository, then pip can just require the latest setuptools by default and then execute the backend according to the standards. In other words, it move all of the monkeypatching and hackery out of pip and into setuptools, where it belongs.

This change brings setuptools into very basic compliance with PEP 517.
@ghost ghost mentioned this pull request Jul 1, 2017
@ghost
Copy link
Author

ghost commented Jul 5, 2017

@ncoghlan Can you specify the additonal concerns for out-of-tree builds?

@ghost
Copy link
Author

ghost commented Aug 5, 2017

@pfmoore @dstufft

Hello all:

I have been attempting to resolve the horrible easy_install behavior where compiled wheels published on pypi are not used to fulfill setup requirements. To address this issue, I have submitted pull requests to both setuptools and pip that would allow a proprietary communication method that can later be easily adjusted to be fully PEP 517 compliant, saving work while resolving a specific issue.

However, everyone appears to be ignoring these pull requests, in my estimation, because PEP 517 is not fully completed. That’s fine, but partial PEP 517 compliance in one area is better than nothing at all, which is currently the default scenario.

@ghost ghost changed the title py517: implement get_build_requires Wip: py517: implement get_build_requires Aug 24, 2017
@ghost ghost changed the title Wip: py517: implement get_build_requires WIP: implement PEP 517 Build Backend Aug 25, 2017
@ghost
Copy link
Author

ghost commented Aug 31, 2017

So just as a reference we need to use wheel.egg2wheel to convert egg_info to dist_info.

self.fetch_build_eggs(attrs['setup_requires'])
if skip_install_eggs:
raise SetupRequirementsError(attrs['setup_requires'])
else:
Copy link
Member

Choose a reason for hiding this comment

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

You don't need the else block here.

@@ -25,6 +25,14 @@
from .py36compat import Distribution_parse_config_files


skip_install_eggs = False
Copy link
Member

Choose a reason for hiding this comment

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

This variable appears to be undocumented and untested. It could be optimized away.

I wonder if instead of setting a global flag that tweaks the inner behavior of the Distribution object for all users if it wouldn't be better for the caller that would use this functionality to instead create a:

class Distribution(setuptools.dist.Distribution):
    def fetch_build_eggs(self, eggs):
        raise SetupRequirementsError(...)

It's not yet clear to me where a user or application would hook into this behavior.

Also, the name 'skip_install_eggs' doesn't match the behavior. It's 'fail on install eggs'.

Copy link
Author

Choose a reason for hiding this comment

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

This variable is for internal use only. The public api is get_requires_for_build_wheel

@jaraco
Copy link
Member

jaraco commented Sep 3, 2017

What's the status of this PR? It's still tagged WIP, yet one comment says it's good to go. Other comments still say "we need", suggesting there's more work to be done.

I've added some comments about the implementation. I'm generally fine with new pep517 module, but I'm reluctant to add implicitly-defined hooks that complicate the (already complicated) behavior. I've suggested another possible approach which may prove simpler, but first, I think we need to understand how it is that this behavior is intended to be used.

@ghost
Copy link
Author

ghost commented Sep 3, 2017

What's the status of this PR? It's still tagged WIP, yet one comment says it's good to go. Other comments still say "we need", suggesting there's more work to be done.

The reason for this is that the PEP was modified after it was initially accepted. It's not currently acceptable to merge. I'm working on the pip side of the chain first and will then update this.

@ghost ghost changed the title WIP: implement PEP 517 Build Backend Implement PEP 517 Build Backend Sep 4, 2017
@ghost
Copy link
Author

ghost commented Sep 4, 2017

@jaraco Let's go ahead and get this in here as the pip people seem to be taking their time.

@@ -25,6 +25,14 @@
from .py36compat import Distribution_parse_config_files


_skip_install_eggs = False

Copy link
Author

Choose a reason for hiding this comment

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

So again I want to emphasize that this is an internal setuptools implementation detail that should not be used outside of setuptools.

def get_requires_for_build_sdist(config_settings=None):
config_settings = fix_config(config_settings)
return get_build_requires(config_settings)

Copy link
Author

Choose a reason for hiding this comment

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

These two get_requires functions are the public API. They will be used by pip to determine the setup requirements.

@ghost
Copy link
Author

ghost commented Sep 4, 2017

I've suggested another possible approach which may prove simpler, but first, I think we need to understand how it is that this behavior is intended to be used.

I added some tests that should help clarify this matter. Let me know if you have any other questions.

def prepare_metadata_for_build_wheel(metadata_directory, config_settings=None):
sys.argv = sys.argv[:1] + ['dist_info', '--egg-base', metadata_directory]
_run_setup()

Copy link
Author

Choose a reason for hiding this comment

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

This will start working once pypa/wheel#190 is merged but there is no need to wait for that.

@ghost ghost mentioned this pull request Sep 4, 2017
@ghost ghost closed this Sep 8, 2017
@ghost ghost deleted the py517 branch September 8, 2017 02:42
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants