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
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev