GSoC Proposal

Mojca Miklavec mojca at macports.org
Wed Mar 27 08:40:22 UTC 2019


Dear Karan,

I'm just answering a small part of your question here, a bit more about upt
while CC-ing its author & potential mentor:

On Tue, 26 Mar 2019 at 18:15, KARAN SHETH <karan.sheth at somaiya.edu> wrote:

>
>
>> (Another option for a project in Python would be bringing universal
>> packaging tool [1] to MacPorts.)
>>
>
> I looked in to this option and it looks very exciting, this is what I have
> understood so far about bringing upt to MacPorts :
> - A UPT-Frontend and Backend will have to be created for macports.
>

No, MacPorts in itself requires writing just a backend to support creating
packages for existing frontends (currently there are frontends for pypi,
ruby gems, cpan), but you usually need a separate backend for each of the
frontends. However, it would be great to maybe create new frontends for
npm, cabal, ... (npm would be particularly helpful). And if working on that
project, it would make sense to concentrate on at least one frontend (ruby
gems, npm, or something else) and try to make some awesome improvement of
our packages. Our ruby packages are so outdated that they are literally
useless, haskell support is horribly lagging behind as so much manual work
is needed (we would like to provide the latest version of pandoc), and npm
support is basically non-existent.

The work would most likely include doing various improvements to UPT
itself. In particular, the biggest problem would be how to keep packages
up-to-date after the initial creation. We currently have 1000+ perl
packages, plenty of python packages etc. and it's a pain to keep them up to
date. When packages change, new dependencies are added, and none of that is
currently automated. The current version of UPT support creating the inial
version of the package, but there is no mechanism in place yet to keep
package updated afterwards (incorporating other changes you might have made
to the Portfile itself).


> So the Frontend will take the Portfile from macports and convert it using
> UPT.
>

No, the frontend would take a package from pypi / cpan / ruby gems / npm /
... and generate a Portfile.


> But my doubt is, what is the UPT-Backend in this case, I know it should be
> MacOS but like in the example given on UPT repo its converts json from PYPI
> into Guix Pxg Definition.
> So same way, what would UPT do in case of Macports?
>

Generate a Portfile


> I may be completely wrong here as I have no prior knowledge about UPT.
>

You aren't expected to have any prior knowledge about it. It's relatively
new, currently one-person project, but we had quite some GSOC projects in
the part to do various conversion from X to Portfiles (from pypi, cpan),
and supporting such a project would solve a lot more packaging nightmares
all at once.

This is some example code that was cooked together in cca. two hours:
    https://github.com/mojca/upt-macports

I would need to add some documentation, but once you set it up, the command
like
    upt package -f pypi -b macports upt
would create a MacPorts package for the "upt" package (that's the last
argument) as fetched from pypi (frontend pypi, backend macports, package
upt).


> Now seeing that I have two choices - first to continue making the django
> app or to make upt, I will first look into UPT after my doubts raised above
> have been clarified and then decide which route to take.
>

The choice is yours, you can also submit two proposals, but it makes most
sense to really create one awesome proposal rather than trying to submit
three, none of which you had a substantial time to do properly. (Or make
one really awesome proposal, and a backup one.) If more than one student
applies for the same project, we can only select one, but it really makes
most sense to apply for the one that you are most likely to shine in.

If you plan to apply for this project, what you might want to look into is
approximately the following:
- get familiar with cpan2port & pypi2port to generate perl and python
packages (install it via macports, figure out how to use it, try to create
a package, take a glimpse at the source code)
- figure out how to create and / or modify perl / python / ruby / ...
packages
- get familiar with using "port livecheck", maybe find some outdated
package that you are using and try to update it (if your interest is in
python, search for ports inside "python")
- try to install UPT (maybe via virtualenv & pip) and find out how to
generate a package with an existing backend (the macports backend on the
link above should also be able to generate super simplified python
packages, but it's not yet complete)
- you could check https://trac.macports.org/ticket/48324 /
https://lists.macports.org/pipermail/macports-dev/2018-March/037531.html just
to get an idea about haskell issues and lack of automation there

I just quickly listed some task, feel free to ask for help at any given
point. For any questions specific to UPT I count on Cyril to help you.
Michael: may I count on you for help with any general port-related
questions?

I didn't write anything about Django app in particular as you'll find tons
of information in the mailing list archives, so please ask if you have any
particular question there.

Mojca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20190327/f07c36f7/attachment.html>


More information about the macports-dev mailing list