GSoC Proposal

[KARAN SHETH]

Hey,

On Mon, Apr 1, 2019 at 8:08 PM Renee Otten <ottenr.work at gmail.com> wrote:

> 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 have removed the webUI from the proposal now.

> 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.
>

Is it possible to rename the existing Python ports as per PYPI so that
issues of duplicates ports can be avoided?
If renaming is not possible and if there's a pattern like  “py-codestyle”
in MacPorts, but “pycodestyle” on PyPI then we can query for both
combination to see if the port exists or not and then decide accordingly,
though this would be slower and practically double the number of queries
but just a possible solution.

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).
>

I used port lint today for the first time and still not sure what exactly
it does so first I will understand it.
As far as I understood port lint check for any syntax error in the ports
I guess it would be great to add the auto sub port linting feature.

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
>

I guess that would be the plan.

4) ideally the “python_requires” information should be used to only add the
> supported versions that are present in the default “python.versions” field
>

Yeah sorry as of now I had kept it static, it would be dynamic in future
and will only have supported versions.

5) there is no need to add the “md5” checksum
>

Ok

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.
>

I agree on this and have updated the proposal accordingly.

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
>
>
Thanks very much for review.
Is there any other goals or tasks that can be taken under this project?

Thanks,
Karan Sheth

-- 

 <https://www.somaiya.edu>        <http://www.somaiya-ayurvihar.org>  
<http://nareshwadi.org>  <http://somaiya.com>  <http://www.helpachild.in>  
<http://nareshwadi.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20190402/2bf901fc/attachment.html>