Work around breaking install

[reebalazs]

... due to dot replaced to dash in module name.

See pypa/setuptools#4853 and #25

[mister-roboto]

@reebalazs thanks for creating this Pull Request and helping to improve Plone!

TL;DR: Finish pushing changes, pass all other checks, then paste a comment:

@jenkins-plone-org please run jobs

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass, but it takes 30-60 min. Other CI checks are usually much faster and the Plone Jenkins resources are limited, so when done pushing changes and all other checks pass either start all Jenkins PR jobs yourself, or simply add the comment above in this PR to start all the jobs automatically.

Happy hacking!

[ale-rt]

This cannot be merged unluckily.

If you have a package called foo.bar_baz it will not be found...

[reebalazs]

@ale-rt hmmm ok. I mean... the fix won't work for foo.bar_baz because it will attempt to install foo_bar_baz and fail, but it will fail in the same way as without the workaround.

However it will work for foo.bar.baz which is the typical case.

Let's hope that the real reason gets fixed and we won't need this. Until then... I'll use this branch as a workaround.

[ale-rt]

@ale-rt hmmm ok. I mean... the fix won't work for foo.bar_baz because it will attempt to install foo_bar_baz and fail, but it will fail in the same way as without the workaround.

However it will work for foo.bar.baz which is the typical case.

Let's hope that the real reason gets fixed and we won't need this. Until then... I'll use this branch as a workaround.

@reebalazs the thing is quite complex...
I agree with you, the canonical use case is foo.bar.baz, but I saw many times already packages like foo.bar_baz.
Years ago those names were normalized by setuptools like foo.bar-baz (this is why if you have to pin them you need to specify foo.bar-baz = 1.0.0 as foo.bar_baz = 1.0.0 will be ignored).

As of today, I have no clue if it is the same because the packaging story evolved quite rapidly.

[reebalazs]

To clarify what I mean:

I agree that the patch won't work to fix foo.bar_baz. So it does not work for all the cases. But if foo.bar_baz is not failing due to the original issue, it will continue to work. If it's failing, it will continue to fail. So the patch fixes a lot of the problems, and it does not fix all the cases, but it also does not make them worse.

Right now this is "good enough" for me because I don't have any failure with foo.bar_baz packages, and the patch fixes the foo.bar.baz cases.

We are in a pickle if we see any foo.bar_baz breakages, because we'd have to fix them one-by-one, but by the time I hope we (or someone) will figure out the real solution to the problem.

[ale-rt]

I see your point @reebalazs and you are probably right :)
First step would be fix plone.autoinclude tests.

[reebalazs]

I see your point @reebalazs and you are probably right :) First step would be fix plone.autoinclude tests.

The actual fix would be to figure out why it gets the underscore at the first place. Anything else is just a workaround.

[mauritsvanrees]

I am first looking into the failing tests, which had already been failing longer, simply due to testing too old Python versions.
See PR #27.

Some tests will still fail due to the newer setuptools version. A quick test of the above fix did not yet help here.

Curiously, locally on Python 3.9, 3.10 and 3.11 the tests pass. Only the integration tests for 3.12 and 3.13 fail.

[reebalazs]

Unfortunately this is not enough. Beyond autoinclude, I get other errors for example from collective.timedevents:

__version__ = pkg_resources.get_distribution("collective.timedevents").version

pkg_resources.DistributionNotFound: The ‘collective.timedevents’ distribution was not found and is required by the application

This fails too, while the package is successfully installed. So this indicates that the place to work around this is not in autoinclude, but the original problem in setuptools has to be fixed.

[ale-rt]

I have it... This should do it:

Instead of using:

(Pdb++) iter_entry_points
<bound method WorkingSet.iter_entry_points of <pkg_resources.WorkingSet object at 0x7192638f6b50>>

We should use the equivalent importlib function:

importlib.metadata.entry_points(group="z3c.autoinclude.plugin")[0].dist.name

See: https://importlib-metadata.readthedocs.io/en/latest/migration.html

[mauritsvanrees]

Or something like this:

    (Pdb) from importlib.metadata import distribution
    (Pdb) distribution("example-zopeaddon").name
    'example.zopeaddon'
    (Pdb) distribution("example_zopeaddon").name
    'example.zopeaddon'
    (Pdb) distribution("example.zopeaddon").name
    'example.zopeaddon'

[ale-rt]

I think this should be replaced by #28. As you suggest the way to go is to use importlib dist name

[ale-rt]

I think this should be replaced by #28. As you suggest the way to go is to use importlib dist name

#30 is definitely better!

[mauritsvanrees]

Fixed in release 2.0.0.