Restore custom distutils handling for resolving paths to submodules.

[jacobtylerwalls]

Steps

• For new features or bug fixes, add a ChangeLog entry describing what your PR does.
• Write a good description on what the PR does.

Description

I understand @DanielNoord wants to bisect before evaluating a path forward. But this test case fails without these changes, so it could be a sufficient way forward.

Type of Changes

	Type
✓	🐛 Bug fix

Related Issue

Closes pylint-dev/pylint#5645

[DanielNoord]

I wonder how we can fully test this..
This does seem like it would work though.

@cdce8p What do you think? Try this and see if the problems go away?

[jacobtylerwalls]

I wonder how we can fully test this..

I mean, we could add the CI step in this PR if we really want to have an extra workflow that only runs one corner case!

[Pierre-Sassoulas]

Thank you @jacobtylerwalls. We just need to remove the temporary CI job before merging, right ?

[DanielNoord]

Do we though? Won't the CI job be a nice test to see this actually works?

[jacobtylerwalls]

Fine with me. I added caching to make it more efficient.

[cdce8p]

The change looks like it should work! I'm just not sure that we should run the CI job for every time. It's excellent to have but maybe better as part of an optional CI suite?

What do you guys think about moving it to a separate workflow file and using the workflow_dispatch event to trigger it whenever we need to? For that case, it would make sense to add a small comment in the code mentioning the workflow and that it can be run manually. Lastly, the caching could probably be removed. Although slightly more efficient, it can also create unexpected issues. If only run on request, there likely won't be any cache which can be restored to begin with.
https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow

An alternative would be to add if: false to the job. It would also be trivial to change it to true whenever we need to work on it (which itself shouldn't be all too often).

After writing this, I'm just slightly leaning towards the latter option.

[jacobtylerwalls]

I'm thinking along the lines of the former option: what about creating a "release testing" CI workflow with on: workflow_dispatch, and then adding a reminder to the release.md checklist to remember to run it before releases?

[cdce8p]

I'm thinking along the lines of the former option: what about creating a "release testing" CI workflow with on: workflow_dispatch, and then adding a reminder to the release.md checklist to remember to run it before releases?

Had another idea after reading "release testing", why not trigger on push of tags and workflow_dispatch?

[Pierre-Sassoulas]

why not trigger on push of tags and workflow_dispatch?

The issue is then that we can tag buggy commit and have nothing released. Removing or renaming a tag and its associated milestone, then fixing the issue and doing another tag if something fail is more complicated than just launching locally.

[cdce8p]

The issue is then that we can tag buggy commit and have nothing released.

The idea was to have run automatically for every release. I still wanted to keep the manual trigger.
You do have a point though that deleting a tag is quite some work. Let's do just the workflow_dispatch trigger then with a note in release.md as suggested.

[cdce8p]

Thanks @jacobtylerwalls 🐬

[DanielNoord]

@ everybody, do we want to test this as well in pylint? I don't think so right? (Seeing the difficulty of doing so in astroid). If not we can also close the pylint issue I think.

[cdce8p]

@ everybody, do we want to test this as well in pylint? I don't think so right? (Seeing the difficulty of doing so in astroid). If not we can also close the pylint issue I think.

Yeah, let's close the pylint issue. The test here should be enough.