Rename meta_requires to run_requires_exact

[qwcode]

"Meta" is a pretty content free prefix that doesn't really give any hint as to how "meta_requires" differs from "run_requires".

We could potentially renaming "meta_requires" to the more self-explanatory "run_requires_exact".

As part of this, the ":meta:" implied extra would be removed - the ":run:" extra would cover both "run_requires" and "run_requires_exact".

This also leaves open the option of potentially allowing version pinning for build, test and dev dependencies at some point in the future.

---

migrated from https://bitbucket.org/pypa/pypi-metadata-formats/issues/51/rename-meta_requires-to-run_bundles

Updated: original suggestion was for "run_bundles"

[dholth]

Neither makes any sense to me.

[xavfernandez]

Neither makes any sense to me.

hehe, I thought exactly the same thing ^^

[ncoghlan]

The alternative is allowing version pinning in *_requires, and I'm adamantly opposed to that. Software publishers only rarely take system integrators into account, and disentangling their overspecified claimed requirements from their actual requirements is a major ongoing source of pain in software construction (as well as granting their dependencies freedom to be completely cavalier about making backwards incompatible changes). I want the friction of not allowing it in *_requires by default, while still making it possible.

While it's technically correct, I don't like "run_pins" due to the problem with "pins" being both a noun and a verb (and this particular use of the word being relatively arcane dependency management jargon).

Something more verbose like "run_requires_exact" would both provide the desired separation and convey the intended meaning.

[dstufft]

It may be that I just haven't noticed it, but is there a lot of use of == or === inside of install_requires that I just haven't noticed or is it solving a theoretical problem that isn't really occurring much in practice?

[ncoghlan]

Just the "abstract vs concrete dependencies" issue you talk about here: https://caremad.io/2013/07/setup-vs-requirement/

You're right it may not be worth the hassle, though, and I'd be better off simplifying things and just dropping the restriction entirely.

[dholth]

We could try to solve the integrator's problem by making things more complicated for the publisher who is kindly providing us with free labor. Their alternative is to not provide our metadata at all or to decline to publish. A different thing we could do would be to design an override mechanism whereby the integrator can say "actually package x requires y". Often solving part of the problem simply is best because the solution will be tractable and get more usage.

When I'm doing deployments version qualifiers get added to my own or to other's packages only when "the latest version" breaks, or if I want to force an upgrade from a too-old version of a dependency, or if I need to resolve conflicting dependencies between multiple packages. I will occasionally patch an .egg-info/requires.txt or the source package to make that happen. For example in buildout you can apply patches to packages before they are installed.

[ncoghlan]

Yeah, I'm convinced - I'll reject this, and create a new issue for ditching the distinction.

[ncoghlan]

#38 is the replacement issue that suggests just dropping the entire idea of meta_requires