GSoC Proposal

[Renee Otten]

hi Karan, Mojca, Cyril, 


I am happy to help with testing and provide feedback. I quickly glanced over the proposal draft and agree with what Cyril said; in addition, there is a figure showing a WebUI that is not described (personally I am not sure if that would be needed anyway). 

I agree that the most important thing is to (i) make the most accurate and syntactically correct Portfiles and (ii) provide an update mechanism. See below for a few consideration with respect to the MacPorts backend for PyPI, but some might apply to other backends as well.

1) while generating the dependency list, please keep in mind that not all Python ports follow the PyPI naming scheme (with respect to capitalization amongst others). For example the same package is called “py-codestyle” in MacPorts, but “pycodestyle” on PyPI. We probably should follow the PyPI naming scheme in the long run, but in cases like this you wouldn’t want to (recursively) create a “pycodestyle” package that effectively duplicates a port.
2) testing whether dependencies are present already in MacPorts could be done using “port lint”. If the idea is to use that, it would probably be good to extend the functionality of “port lint” to automatically do the linting on sub-ports as well (instead of needing to call it on every sub-port again).
3) if there are version requirements specified for dependencies it would be great to check whether these are met, in addition to just checking whether a port for that package is present
4) ideally the “python_requires” information should be used to only add the supported versions that are present in the default “python.versions” field
5) there is no need to add the “md5” checksum

As Cyril said, updating existing packages should be implemented only once after considering the best option. I would imagine that the only things the “update” function should touch in an existing portfile are “version, revision, checksums, depends_build, depends_lib, depends_run”. All other lines in the existing portfile should stay the same and care has to be taken to minimize formatting changes as not to pollute the diff. The easiest way (in my mind) is just to use the “upt package”  command to generate a “new" portfile for the package, parse the existing portfile and only swap the above-mentioned fields for the newly generated ones.

Again, these are just some initial thoughts and I will take a closer look at upt and the work you have done so far. I hope this helps and let me know if you have any questions. 

Best,
Renee


> On Apr 1, 2019, at 5:39 AM, Mojca Miklavec <mojca at macports.org> wrote:
> 
> Dear Karan,
> 
> Just a few quick notes (for others as well).
> 
> On Sun, 31 Mar 2019 at 22:00, KARAN SHETH via macports-dev wrote:
>> 
>> I have uploaded the project.
>> Macports-Backend :  https://github.com/Korusuke/upt-macports
>> NPM-Frontend : https://github.com/Korusuke/upt-npm
> 
> Awesome, thank you very much.
> 
> Cyril: what's your desired destination for such work? I would suggest
> placing the repositories on either
>    https://framagit.org/upt
> or create a repository under
>    https://github.com/macports-gsoc
> and do the pull request and code review on either of these places
> (just one though), and once the review is done, try to make some
> release (even if a beta one) if that part of the code is ready. Cyril,
> do you have a github account?
> 
> Renee (or anyone else from this list who's familiar with writing
> portfiles etc.), could you please assist in testing the resulting
> packages and providing feedback from the MacPorts point of view?
> 
> What I would like to suggest is for Karan to try to submit a PR for a
> new port py-upt (except that this might be a bit tricky at this point
> before the macports backend is included; thus the suggestion to make a
> beta release).
> 
> In any case I would be grateful if some MacPorters could help testing,
> guiding, providing feedback etc.
> 
> Thank you,
>    Mojca