feature request: add entrypoint so that pip-installation puts a cq-cli binary in bin/
justbuchanan opened this issue · comments
This is fairly minor, but after doing pip install git+https://github.com/cadquery/cq-cli, I can do python -m cq-cli, but I'd like to do just cq-cli.
I found that you can add an entry to pyproject.toml to achieve this:
# pyproject.toml
[project.scripts]
cq-cli = "cq-cli:main"However... pip/setuptools doesn't seem to like the hyphen and/or the way the file tree is structured:
ERROR: For req: cq-cli==2.1.0. Invalid script entry point: <ExportEntry cq-cli = cq:None []> - A callable suffix is required. Cf https://packaging.python.org/specifications/entry-points/#use-for-scripts for more information.
It seems like the issue is the "-" in "cq-cli.py", so I tried renaming it to "cq_cli.py". Pip then says install was successful and puts a "cq-cli" binary in bin/, but now the "cqcodecs" directory doesn't get copied in on install...
I was able to get things working by making a cq_cli directory and moving everything inside of it, but I feel like there should be an easier way. https://github.com/justbuchanan/cq-cli/tree/entrypoint
I'm pretty sure there is a way to do this properly through puproject.toml, and it is something I've thought about looking into. If you figure it out before I get around to it, please feel free to open a PR.
I was able to get this to work with pyproject.toml, but only with changes to the overall directory/file structure of the project. The entrypoint branch on my repo shows this working.
The added benefit of moving things into a subdirectory is that cq-cli.py and cqcodecs don't show up directly in your site-packages directory. Instead they're all grouped under one cq_cli directory/module, which seems a little better. Note that pip doesn't like "-" in module names because it's not a valid identifier in python. The entrypoint/binary can still be cq-cli with a "-" however.
If you're ok with moving things to a subdirectory and renaming cq-cli.py to cq_cli.py, I'd be happy to fix the tests / clean it up and send a PR.
This is going to break PyInstaller as well.
There are PEP(s) that define a standard project structure, with the main difference from your structure being a top-level src directory. Sample documentation here. If we're going to go through the pain of restructuring this repo, maybe we should make sure it complies with that documentation. I think I would also take the opportunity to add a lint check in CI since we're breaking things anyway.
@justbuchanan I added you as a maintainer on this repo. I will create a branch for restructuring tomorrow (Monday) and you should be able to push to that if you would like to fix the tests. I will work on straightening out CI and PyInstaller on that branch once the basic structure is in place.
@justbuchanan I have done the initial restructuring here. I did a quick test installation of the generated .whl file and it seemed to work fine. Let me know if you see any issues. I'll start fixing CI and PyInstaller.
Thanks! I took a quick pass at updating tests in #24. I opened it as a separate PR to avoid conflicts with yours, but if it's preferable, I can just push to your PR branch.
@justbuchanan Can you put the latest commit to the restructure branch through its paces? "It works on my machine", but I want to make sure you can install and run it as expected. The last thing that I think needs to be fixed is PyInstaller in CI, but act has some Python-related bugs in their issue tracker that are blocking me from fixing it locally. I think I'll have to fix it after we merge this.
@justbuchanan I think this issue can be closed now. The PyInstaller builds are running (although the builds need testing), and I added a section on installation via pip to the readme.