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

pip-wheel-metadata configurable #6213

Closed
gaborbernat opened this issue Jan 28, 2019 · 20 comments · Fixed by #6325 or sohonetlabs/nameko-rediskn#2

Comments

@gaborbernat
Copy link

@gaborbernat gaborbernat commented Jan 28, 2019

At the moment pip generates a pip-wheel-metadata folder right alongside the setup.py. Can we move this to some other temporary folder via some flag/environment variable to not pollute the project source directory once someone does a pip install .? Thanks!

@pradyunsg

This comment has been minimized.

@pfmoore

This comment has been minimized.

Copy link
Member

@pfmoore pfmoore commented Jan 28, 2019

@pradyunsg Yeah, looks like that comment got missed, sorry!

@gaborbernat

This comment has been minimized.

Copy link
Author

@gaborbernat gaborbernat commented Jan 28, 2019

I would like this to be not hardcoded from my end. E.g. inside tox I would like to move it into some VCS ignored internal folder.

@pradyunsg

This comment has been minimized.

Copy link
Member

@pradyunsg pradyunsg commented Jan 28, 2019

@pradyunsg Yeah, looks like that comment got missed, sorry!

No worries. ;)

It's not too late to change it IMO.


@gaborbernat Would build/pip-wheel-metadata/ not work for your usecase? If so, why?

@gaborbernat

This comment has been minimized.

Copy link
Author

@gaborbernat gaborbernat commented Jan 28, 2019

I like to my working directory clean, and adding a build folder into it is part of this. By default could be there but if not a big trouble let's allow for the user to move it to some other folder that exists (e.g. .tox).

@pradyunsg

This comment has been minimized.

Copy link
Member

@pradyunsg pradyunsg commented Jan 28, 2019

Well, setuptools builds will result in a build/ folder when building, so it's not going to result in an extra directory then.

It's already in most .gitignore files so I think it'll be okay (much like dist/* is a convention for final build artifacts, build/* could be for intermediate ones).

@gaborbernat

This comment has been minimized.

Copy link
Author

@gaborbernat gaborbernat commented Jan 28, 2019

But what if I'm not using setuptools?

@gaborbernat

This comment has been minimized.

Copy link
Author

@gaborbernat gaborbernat commented Jan 28, 2019

tox e.g. uses .tox/dist for final build artifacts. I'm fine with having inside builds by default, but let's keep this configurable at least via some environment variable.

@pradyunsg

This comment has been minimized.

Copy link
Member

@pradyunsg pradyunsg commented Jan 28, 2019

Cool cool -- I'm not opposed to keeping it configurable; I just want to avoid adding too many knobs. :)

(should've stated this earlier)

@gaborbernat

This comment has been minimized.

Copy link
Author

@gaborbernat gaborbernat commented Jan 28, 2019

I agree, that's why I suggested the environment variable (to make it a more subtle knob) than an extra CLI flag. it's meant more for tools building on top of pip and advanced users.

@pradyunsg

This comment has been minimized.

Copy link
Member

@pradyunsg pradyunsg commented Jan 29, 2019

I'd prefer to add a CLI option that's hidden -- it'll use the existing setup so won't be a special case in any form. :)

@pradyunsg

This comment has been minimized.

Copy link
Member

@pradyunsg pradyunsg commented Jan 29, 2019

@pfmoore Does the above sound OK to you?

@pfmoore

This comment has been minimized.

Copy link
Member

@pfmoore pfmoore commented Jan 29, 2019

I have no problem with that - it seems like more complication than I'd expected to need to make the location configurable, but given that @gaborbernat has a concrete use case for it, we should support it.

[On a broader note, I'm concerned about how many configuration settings pip is growing - we're already seeing problems from unexpected interactions between options that we'd never considered, so I'd prefer caution when adding more, but there's no reason to deny this specific request over a vague and general "concern"]

@dstufft

This comment has been minimized.

Copy link
Member

@dstufft dstufft commented Jan 29, 2019

Speaking to @pfmoore last point, the feels like something where we don't need a configuration knob. Unless I'm mistaken, this directory doesn't need to persist between invocations of pip, so why not just always put it in a temporary location instead of pooping it into the current directory?

@pradyunsg

This comment has been minimized.

Copy link
Member

@pradyunsg pradyunsg commented Feb 3, 2019

@dstufft Good idea -- let's do that.

@hugovk

This comment has been minimized.

Copy link
Contributor

@hugovk hugovk commented Mar 11, 2019

Please see PR #6325.

@ei-grad

This comment has been minimized.

Copy link

@ei-grad ei-grad commented Mar 20, 2019

Hi everybody. It looks not so critical maybe, but IMO it is still quite a big issue because it affects many users. What is the stopper here?

Also, is it technically possible to add the check in tests that pip would never behave in such undesirable way again? I mean that it shouldn't place any its utility files in the project working space (excluding the build/dist/*.egg-info and "hidden" directories). How such behavior/regression tests could look like?

mildbyte added a commit to splitgraph/splitgraph that referenced this issue Apr 12, 2019
…n't conflict with downstream builds (mitigation for pypa/pip#6213)

* Ran a `poetry lock` to bump dependencies
mildbyte added a commit to splitgraph/splitgraph that referenced this issue Apr 12, 2019
…n't conflict with downstream builds (mitigation for pypa/pip#6213)

* Ran a `poetry lock` to bump dependencies
mildbyte added a commit to splitgraph/splitgraph that referenced this issue Apr 12, 2019
…n't conflict with downstream builds (mitigation for pypa/pip#6213)

* Ran a `poetry lock` to bump dependencies
jbarlow83 added a commit to jbarlow83/OCRmyPDF that referenced this issue Apr 23, 2019
@cas--

This comment has been minimized.

Copy link

@cas-- cas-- commented May 1, 2019

Still no movement on this? I just found this directory popping up in project root!

Why not set it to be in within build dir now and then consider about configuring it, it's been 4 months and several releases without being addressed and devs keep having to add it to .gitignore

cas-- added a commit to cas--/Deluge that referenced this issue May 3, 2019
 * Using pyproject.toml for black config pip version 19.1 errors out
   about using editable install with pyproject.toml.
   Workaround is to not use pip 19.1 in tox.
 * Pin to 18.1 to avoid pip-wheel-metadata-folder creation

Ref:
 - pypa/pip#6434
 - pypa/pip#6213
@Rotonen

This comment has been minimized.

Copy link

@Rotonen Rotonen commented May 15, 2019

This also breaks parallel tox builds where the package itself is installed in development mode for an install time speedup.

@gaborbernat

This comment has been minimized.

Copy link
Author

@gaborbernat gaborbernat commented May 22, 2019

This issue just seems to be waiting for an interested community member to do the work 👍

ewenmcneill added a commit to ewenmcneill/TinyFPGA-Bootloader that referenced this issue Jun 8, 2019
"pip-wheel-metadata" is created alongside setup.py, by "pip install ."
(used for development).

See pypa/pip#6213 for discussion of this
clutter (issue currently open; might be moved to another location,
eg build/pip-wheel-metadata or .pip-wheel-metadata, in a later version).
@cburgdorf cburgdorf referenced this issue Jul 23, 2019
0 of 2 tasks complete
@lock lock bot added the S: auto-locked label Oct 5, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
8 participants
You can’t perform that action at this time.