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

Using pyproject.toml triggers special pip behavior #123

Closed
exarkun opened this issue Aug 6, 2018 · 6 comments
Closed

Using pyproject.toml triggers special pip behavior #123

exarkun opened this issue Aug 6, 2018 · 6 comments

Comments

@exarkun
Copy link
Member

exarkun commented Aug 6, 2018

I shouldn't have to kick pip into a new, incompatible mode just to configure towncrier. towncrier should provide an alternate configuration mechanism that avoids pep 518 and pyproject.toml completely.

@exarkun
Copy link
Member Author

exarkun commented Sep 5, 2018

One possible work-around would be to add an option to specify a file to use instead of pyproject.toml. If an alternately named file is used it won't trigger the special processing from pep 518.

@zgoda-mobica
Copy link

This becomes even more problematic with pip 19:

editable mode is not supported for pyproject.toml-style projects. pip is processing this project as pyproject.toml-style because it has a pyproject.toml file. Since the project has a setup.py and the pyproject.toml has no "build-backend" key for the "build_system" value, you may pass --no-use-pep517 to opt out of pyproject.toml-style processing. See PEP 517 for details on pyproject.toml-style projects.

This requires special pip switches for editable installs.

@mauritsvanrees
Copy link
Contributor

I don't know what the original issue text means, but the comment from @zgoda-mobica made me look up that message from pip.
Apparently more people have complained about this pip behavior, see this thread. (I haven't fully read it.)
And a couple of hours ago, a pip PR was merged that reverts the changes that caused the editable mode problem. So should be fixed with a new pip release.

@exarkun Is this the problem you meant or was it something else?

@exarkun
Copy link
Member Author

exarkun commented Apr 30, 2019

Note the issue was filed more than 4 days ago so I don't think the recently merged pip PR solves the issue.

I'll try to recreate the problem and post more details.

@exarkun
Copy link
Member Author

exarkun commented Apr 30, 2019

Actually, maybe I won't, because #127 was merged and provides a work-around. Not sure why this issue is still open at all.

@exarkun
Copy link
Member Author

exarkun commented May 2, 2019

I'm not sure how to reproduce the original problem now that there's a new pip release with a new behavior, anyway. The problem was probably originally encountered via tox which wants to do extra management of installed versions. The obvious attempt at pinning an older version of pip doesn't produce the problem. Consider #127 is merged I'm not sure it's worth digging through the history further to try to understand. If it's still broken, I'm sure I'll be back. ;)

I'm gonna call this fixed by #127.

@exarkun exarkun closed this as completed May 2, 2019
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

No branches or pull requests

3 participants