Universal packaging tool (for pypi, cpan, ruby, ...)

[Artur Szostak]

What is the current practical reality of tools like upt? i.e. how well do they behave on real packages. For example, if I take all the .src.rpm packages in say the Fedora repository, and attempt to convert them to MacPorts packages, what percentage of the converted packages will actually work out of the box?
I do not necessarily expect every package to work, some are too system specific for that. However, my previous tinkering with such conversion tools showed that the number is close to 0%. The problem was that they only really work for simple packages with basically no dependencies. How does upt improve this situation?

Best regards.

Artur

________________________________________
From: macports-dev <macports-dev-bounces at lists.macports.org> on behalf of Cyril Roelandt <cyril.roelandt at aquilenet.fr>
Sent: 12 February 2019 03:40:50
To: Mojca Miklavec
Cc: MacPorts Development
Subject: Re: Universal packaging tool (for pypi, cpan, ruby, ...)

Hi!

I'm the author of upt.

On 2019-02-10 21:24, Mojca Miklavec wrote:
> Hi,
>
> Last week I was sitting in cafeteria with the author of a new python
> package "upt" (Universal packaging tool) whose aim is to provide
> automatic conversion from one of the repositories like pypi, cpan,
> ruby gems, npm, ... into any other package manager.
>
>     https://framagit.org/upt
>     https://fosdem.org/2019/schedule/event/package_software_with_upt/

The video is not online yet, but should appear on the FOSDEM page soon.
A quick summary: upt is a collection of modules. Some are "frontend"
modules and parse upstream package archives (PyPI, CPAN, ...), others
are "backend" modules, and create a source package suitable for a
downstream distribution (Fedora, OpenBSD, and maybe soon, MacPorts!).

>
> I have a proof-of-concept backend written for python ports, but I
> still need to clean it up a bit and write installation rules before
> publishing (I had no time last week to finish tho work). Some of the
> required functionality in upt was also just implemented now.

What is especially interesting here, is that once this initial work is
available, it will probably be really easy to add support for Perl/Ruby
packages. All that should be required is a Jinja2 template and a couple
of Python methods.

>
> For us this could at some point replace pypi2port & cpan2port (less
> important), but more importantly we have no such tool for ruby gems (I
> believe?), and maybe someone would write a frontend for npm or another
> tricky "package manager" one day.

It is worth noting that, because of the modular nature of upt, every
time someone adds/updates a frontend, the improvements are available for
every single backend (including the MacPorts one Mojca is working on).
This means that all distro developers end up sharing their hard work.

>
> What's currently not implemented are non-python / non-perl
> dependencies, and an easy way to upgrade (it can create the package
> for the first time, but if you make lots of changes, it doesn't know
> how to "merge" the manual changes with changes in the upstream
> package).

Regarding non-Python dependencies in Python packages, I do not think
setuptools allows developers to specify them. Maybe I'm mistaken?

Regarding updates, I think I did not answer your question at FOSDEM.
Sorry about that, it was a bit of a stressful talk, as you may
remember :) How does pypi2port work with upgrades?


Cyril.