Hello,
(tl;dr: I wrote a modular tool that helps people package software from
PyPI/CPAN/etc. to OpenBSD/GNU Guix/etc. and would like some feedback.)
For the past few weeks, I have been working on upt[1], a tool allowing
package maintainers to turn a package available in a language-specific
package archive (such as PyPI or CPAN) into a package for their OS (a
BSD-based system or a GNU/Linux distribution)
Similar tools have been used by various distributions for a long time:
OpenBSD has PortGen. Debian has tools such as cpan2deb, pypi2deb, etc.
RPM-based distributions have {cpan,gem,npm,pyp}2rpm. GNU Guix uses "guix
import".
There are a few issues related to these tools:
- all the tools that parse a given language-specific package archive
(say, PyPI) reimplement the same code;
- most of the tools that output a package definition for a given OS
reimplement the same code (OpenBSD's PortGen does not seem to do that,
though);
- there is usually no unified CLI, which means that package maintainers
have to learn and remember a different syntax for every tool they use
(again, OpenBSD's PortGen has a common CLI for all upstream package
archives);
- there is no unified behaviour: some tools may build the package, some
may not, some tools may download the source tarball, some may not,
etc.
The universal packaging tool (upt) comes as a small core project (upt
itself) that provides a unified CLI allowing package maintainers to use
two types of modules: frontends and backends. Frontends parse
language-specific package archives (PyPI, CPAN, Rubygems...) and
generate a package definition using an internal representation; backends
parse this internal representation and generate a package definition for
a particular package manager. Think of it as some sort of a compiler.
This solves the issues I mentioned above:
- a given language-specific package manager only needs to be parsed by a
single tool; all improvements to this tool will benefit all
distributions;
- a given package manager/OS has only one implementation of the code
required to generate a package: improvements to this tool will be
useful to all the maintainers;
- the CLI is unified;
- the behaviour is simple and similar across all frontends/backends, as
upt does not build the package, does not try to do anything fancy: it
only generates a package definition.
Furthermore, all frontends/backends live in their own git repositories,
so it is especially easy to add one.
You may install upt by running:
$ pip install upt[frontends] upt-openbsd
My dear friend Daniel Jakots is also working on a port for upt.
Upt can package itself:
$ mkdir /tmp/test-upt
$ PORTSDIR=/tmp/test-upt upt package -b openbsd -f pypi upt
[INFO ] [Backend] Creating the directory structure in
/tmp/test-upt/mystuff/pypi/py-upt
[INFO ] [Backend] Creating the Makefile
[INFO ] [Backend] Creating pkg/DESCR
[INFO ] [Backend] You still need to create
/tmp/test-upt/mystuff/pypi/py-upt/distinfo
[INFO ] [Backend] You still need to create
/tmp/test-upt/mystuff/pypi/py-upt/pkg/PLIST
$ find /tmp/test-upt/mystuff/pypi/py-upt/
/tmp/test-upt/mystuff/pypi/py-upt/
/tmp/test-upt/mystuff/pypi/py-upt/Makefile
/tmp/test-upt/mystuff/pypi/py-upt/pkg
/tmp/test-upt/mystuff/pypi/py-upt/pkg/DESCR
A CPAN and a RubyGems frontends are also available : you may try them
out by using "-f cpan" and "-f rubygems".
The tool is not perfect: it may not find all the required depencencies,
it may not always guess the license(s) used by the project. It should do
most of the tedious tasks required to add a port to OpenBSD.
Would you be interested in using such a tool? Any feedback would be
appreciated!
Regards,
Cyril Roelandt.
[1] https://framagit.org/upt/upt
