pypi

Mojca Miklavec mojca at macports.org
Tue Jun 23 08:58:05 PDT 2015


On Tue, Jun 23, 2015 at 5:49 PM, Lawrence Velázquez wrote:
> On Jun 23, 2015, at 10:53 AM, Mojca Miklavec wrote:
>
>> I just prepared a new python module that depends on some "sourceforge
>> defaults".
>
> I don't understand. Don't you have to set "master_sites sourceforge:something" to get this kind of behavior? Could you post the portfile or commit it somewhere?

I'll put it under my user dir, but basically I didn't have to specify
any regex url.

This worked on its own:
    livecheck.regex
"${python.rootname}-(\[a-zA-Z0-9.\]+)\/${python.rootname}-"
and relies on the presence of some rss site from sourceforge.

>> 111 python modules use GitHub setup for example. I can easily imagine
>> that maste_sites between GitHub and pypi will clash (among other
>> things).
>
> So those modules would just include python-1.0 before github-1.0.

That would be horribly confusing even for me.

>> 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.)
>
> The portgroup could certainly be improved, especially for use by non-module ports, but there are ways to do this without introducing an option that just says "yes" or "no".

Which ones are better? Setups seem to be undesirable.
The order of inclusion of the modules certainly shouldn't become the
main way to trigger certain behaviour of ports.

Mojca


More information about the macports-dev mailing list