pip-wheel-metadata configurable

[gaborbernat]

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]

@pfmoore https://github.com/pypa/pip/pull/5743/files#r215839698?

[pfmoore]

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

[gaborbernat]

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]

@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]

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]

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]

But what if I'm not using setuptools?

[gaborbernat]

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]

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]

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]

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]

@pfmoore Does the above sound OK to you?

[pfmoore]

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]

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]

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

[hugovk]

Please see PR #6325.

[ei-grad]

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?

[cas--]

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

[Rotonen]

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

[gaborbernat]

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