reuse-tool
reuse-tool copied to clipboard
fsfe
Fully migrate to `poetry`
This should more permanently deal with problems such as #288.
Super low priority.
Hey @carmenbianca , I was trying to work on this and was able to migrate to pipenv. I had some questions regarding the same, I was also trying to change the build process in Dockerfile and my question is why create a venv inside a container when Docker achieves the same thing? with pipfile Dockerfile was reduced to a couple of lines. My other question was, makefile also needs be modified for using pipfile? Shall I open a PR for the same?
Hey @sjha2048
why create a venv inside a container
I don't think there's actually a good reason for this. Habit? Not sure.
makefile also needs be modified for using pipfile?
Probably yes.
Shall I open a PR for the same?
If you want!
I did a little bit of research (not a whole lot!) into this a while ago. I'm not actually sure what the best approach is. Poetry gets rid of setup.py, which is a little annoying because we currently do some custom stuff in there. The consensus on pipenv appears to be that it's being superceded by Poetry, and that it subtly breaks a lot between updates. The latter matches my experience from when I tried it when pipenv was still relatively new.
Just throwing in the note that setup.py is used for the AUR package of reuse: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=reuse
Not sure whether poetry would be supported in this fashion.
Poetry has an equivalent to python setup.py install in poetry install, I think. I'm not sure how distro packagers normally deal with Poetry stuff, however, so this would be important to keep in mind.
The same needs to be kept in mind for pipenv, I guess. The pipenv-less workflow of using a bare setup.py would still need to be tested/maintained.
An alternative way of fixing #288-like problems is freezing the entire dependency tree in requirements.txt and requirements-dev.txt. Not sure how to cleanly separate the runtime dependency tree from the development dependency tree, though. And not sure how to stay on top of updates (although, admittedly, this is currently also a bump-everything-every-once-in-a-while affair).
Thank you for your insights, @carmenbianca & @mxmehl, I'll dig up a little more about this and get back to you If required.
Just throwing in the note that setup.py is used for the AUR package of reuse: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=reuse
Not sure whether poetry would be supported in this fashion.
poetry build creates a release file, e.g. reuse-0.14.0.tar.gz that contains a setup.py file:
/home/lino/Source/github.com/reuse-tool/dist
├── reuse-0.14.0
│ ├── LICENSES
│ ├── PKG-INFO
│ ├── pyproject.toml
│ ├── setup.py
│ └── src
│ └── reuse
│ ├── _comment.py
│ ├── download.py
│ ├── _format.py
│ ├── header.py
│ ├── __init__.py
│ ├── init.py
│ ├── _licenses.py
│ ├── lint.py
│ ├── __main__.py
│ ├── _main.py
│ ├── project.py
│ ├── report.py
│ ├── resources
│ │ ├── exceptions.json
│ │ ├── exceptions.json.license
│ │ ├── licenses.json
│ │ └── licenses.json.license
│ ├── spdx.py
│ ├── supported_licenses.py
│ ├── templates
│ │ ├── default_template.jinja2
│ │ └── default_template.jinja2.license
│ ├── _util.py
│ └── vcs.py
├── reuse-0.14.0-py3-none-any.whl
└── reuse-0.14.0.tar.gz
What is missing to complete (fore more info, see this initial PR) our migration to poetry is:
- [ ] Basic usage should be documented.
CONTRIBUTING.mdis probably a good destination for this. As a matter of fact, there's some stuff in the README that should probably be moved to that destination, but we can delay that. - [ ] Translations aren't included in the built package. One can use custom build scripts in poetry but it is an undocumented feature as of now. See this issue for more info.
- [ ] The long description is not included in the built package.
- [ ] The license files are not included in the built package.