avoid duplicate install of bin/offlineimap

[sthen]

fixes install with newer versions of tools, which otherwise fails with FileExistsError: File already exists in installer/destinations.py write_file (duplicate install in pyproject.toml [project scripts]). I think this is the "Finally, the bin/offlineimap command is not used, so we probably can remove it" referred to in 4f5b252 (which wasn't done at the time but now seems to be required).

This v1.1 template stands in .github/.

This PR

Add character x [x].

• [ ] I've read the DCO.
• [ ] I've read the Coding Guidelines
• [ ] The relevant informations about the changes stands in the commit message, not here in the message of the pull request.
• [ ] Code changes follow the style of the files they change.
• [ ] Code is tested (provide details).

References

• Issue #no_space

Additional information

[hartwork]

@sthen installation seems to work fine for me:

# cd "$(mktemp -d)"
# python3 -m venv venv
# source venv/bin/activate
# pip install git+https://github.com/OfflineIMAP/offlineimap3@master
# offlineimap --version
8.0.1

How can I reproduce the issue that you are facing?

[sthen]

From a checkout or unpacked tar: python3 -m build; a=$(mktemp -d); python3 -m installer -d $a dist/*.whl

[hartwork]

@sthen thanks!

I confirm the symptom for:

# python3 -m installer -d "$(mktemp -d)" dist/offlineimap-8.0.1-py3-none-any.whl |& tail -n1
FileExistsError: File already exists: /tmp/tmp.5UOY2Lvp4L/tmp/tmp.GmDCDphhPa/venv/bin/offlineimap

I hadn't heard of installer prior to this and its latest release is more than 2 years old. Is it still relevant? Why does it fail like this? Is the bug in installer or in offlineimap3? I don't see any competing entry points in setup.py that would explain the collision. Happy to understand better. Thanks!

[sthen]

installer is still relevant - it's the tool commonly used by various OS packaging systems to install a wheel from a file on disk into a staging directory. It's used partly because it's much simpler than pip, partly because until the very latest version (released this week), pip used setuptools to build, resulting in a bootstrap problem where it's easy to introduce dependency loops.

I guess there aren't many releases partly because it's simple so they aren't needed often, and partly because any changed behaviour is likely to cause big problems for OS packaging.

The issue here is that offlineimap is asking for the script to be installed from two different places - once from this 'script' with the file coming from bin/offlineimap - the other from [project.scripts] in pyproject.toml. If the wheel is installed using pip then it silently uses its own generated script, not the one from bin/ in the offlineimap distribution. Rather than doing this, installer is erroring out rather than silently overwriting. This is the only case I've seen of this in OpenBSD ports in ~1300 packages that are built using installer.

[hartwork]

@sthen thanks for elaborating! So there is a competing pyproject.toml and setup.py and installer takes both into account? Isn't the best fix then to just drop setup.py and setup.cfg altogether? Or it is a bug in installer that both files get a say in things? The current fix seems more like a workaround?

[sthen]

I don't know what the best fix is. installer doesn't see either pyproject.toml or setup.py, it only looks at the contents of the wheel (in this case: a script named offlineimap in the scripts dir, and a directive in entry_points.txt telling it to write a script named offlineimap).

[hartwork]

@sthen with a pyproject.toml file in place, we should probably clarified whether setup.py and setup.cfg and bin/offlineimap can maybe be dropped altogether. @thekix are these files strictly needed for anything today?