Remove module importing hack

[rotu]

Summary of changes

Remove import hack that prevents objects from pickling. This was to support relative imports between vendored dependencies, but such relative imports do not (and should not) exist anyway.

Closes #1888

Pull Request Checklist

• Changes have tests
• News fragment added in changelog.d. See documentation for details

[jaraco]

The comment around this hack is clearly there to protect this code - to indicate its purpose so it's not capriciously removed. I don't see in this PR or in the associated bug an analysis of why this code is no longer necessary. I do agree it's undesirable that the Distribution object isn't pickleable due to this hack, but we'll want to assess and weigh the costs of removing this hack with keeping it. Could you try tracing this code to its inception and see if there's any hint there as to what problem this code solves?

[rotu]

Could you try tracing this code to its inception and see if there's any hint there as to what problem this code solves?

This seems to be its origin, from when extern and _vendor both had their own VendorImporter: a76f5c0#diff-c6950cefad8b244938b76f24a0db9a6a
commit message: "Pop the module off the stack, preventing the 'Version' class from having a different manifestation in packaging than in pkg_resources."

Below is my understanding and may be wrong:

It would have been a problem at that time, since, depending which importer it goes through, you would have a different module object and a different class object, causing isinstance checks to fail.

setuptools/pkg_resources/_vendor/packaging/specifiers.py

Lines 149 to 152 in de5caae

	def _coerce_version(self, version):
	if not isinstance(version, (LegacyVersion, Version)):
	version = parse(version)
	return version

There still is some weirdness which I didn't address and exists both before and after removing this hack. Namely that, while immediate descendants of _vendor (e.g. setuptools.extern.packaging) report (via __name__) as being in the _vendor package, their children (e.g. setuptools.extern.packaging.version) report as being in the extern package instead.

[rotu]

If my understanding is wrong, could you please contribute a test that demonstrates the continued need for this code? I'm obviously wading into unfamiliar waters here, and it would help to have your insight as the originator of the hack.

[jaraco]

Here are my thoughts around when that hack originated.

[jaraco]

Could you please contribute a test that demonstrates the continued need for this code?

A fair and reasonable request. Reading my thoughts from four years ago, it appears to me as if tests were failing without this change. The fact that they're not now suggests that maybe the hack is unnecessary. I tried drafting a test, but I'm not able to ascertain what behavior was faulty without that effect.

I think the goal was that when using this importer, there should be exactly one instance of the imported modules in place... that there shouldn't be both setuptools._vendor.packaging and setuptools.extern.packaging in sys.modules.

I observe that in #1296, I copied the VendorImporter code. I definitely want to avoid allowing those implementations to deviate (and perhaps I should revert d0f7a33 unless revisiting that issue). Ugh. Those two have already deviated (949bd16), and on this line of code that's being removed.

[jaraco]

In this latest commit, I'm applying the same change to both implementations. Tests are passing for me locally. If they pass CI, then my plan is to move forward with this change. If it causes problems, we can capture those issues and add tests around those use-cases, and thanks to the tests you've added here, that expectation should be able to be retained as well.