pypi

Lawrence Velázquez larryv at macports.org
Tue Jun 23 09:20:44 PDT 2015


On Jun 23, 2015, at 11:58 AM, Mojca Miklavec <mojca at macports.org> wrote:

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

Sounds like it's using the "sourceforge" livecheck type. I don't see how that would happen unless you also use the "sourceforge" fetch group or set "livecheck.type sourceforge" (both of which would override the python-1.0 default).

(The livecheck default behavior is admittedly confusing.)


>> So those modules would just include python-1.0 before github-1.0.
> 
> That would be horribly confusing even for me.

I think discussing this makes it sound more complex than it will be in practice.


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

Behavior could be triggered when ports use options that require it. For instance, python-1.0 only creates subports when python.versions is set. It could be fixed to only override phases on a trigger, also.

Again, this is something that sounds more complicated than it actually is in practice.


> The order of inclusion of the modules certainly shouldn't become the
> main way to trigger certain behaviour of ports.

It's not about triggering behavior; it's about precedence. Order of inclusion already matters. It's just that most portgroups that are used together happen to not step on each other's toes.

vq


More information about the macports-dev mailing list