pypi

[Mojca Miklavec]

On Mon, Jun 22, 2015 at 11:29 PM, Lawrence Velázquez wrote:
> On Jun 22, 2015, at 5:18 PM, Mojca Miklavec wrote:
>
>> OK, I agree. Something in the Python PortGroup could take care of
>> these settings, but in any case the defaults should not influence all
>> python ports. You would end up with
>>   PortGroup python 1.0
>>   pypi_something something
>
> I'm not sure how this would happen?
>
> The idea would be to set defaults for master_sites, distname, and livecheck.type (and maybe a couple of others) for module ports (not applications). Explicitly setting those in the port (which lots of Python ports already do) would override the defaults, so the behavior would not change. Most ports would actually shed some boilerplate.

I just prepared a new python module that depends on some "sourceforge
defaults". If you unconditionally change all python modules at once, I
imagine that a number of python modules might break (a careful rework
with enough testing wouldn't be problematic of course).

> What I'm not sure about is the interaction with other portgroups that also set defaults for those. I expect the order of inclusion matters, so python-1.0 should come first. Hopefully the number of Python module ports that use extra portgroups is small.

111 python modules use GitHub setup for example. I can easily imagine
that maste_sites between GitHub and pypi will clash (among other
things).

>> What is a good alternative for them?
>
> I prefer the way the python-1.0 and php-1.1 portgroups work.

One of the very serious problems of python-1.0 is that there is no way
to revert any changes. Ports for some software that is written in C
and would need access to different ${python.foo} variables need to
reinvent the wheel since including "python 1.0" redefines so much that
the portgroup becomes useless (if clang[++] should still be used).
(One such example is gis/grass, but there are others that have to
redefine the complete path to python modules.)

Mojca