Portfile Workflow Advice

[Sean Farley]

On Tue, Jan 15, 2013 at 10:48 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Jan 15, 2013, at 11:48, Sean Farley wrote:
>
>> 1) The gap between Trac and the mailing lists is huge. Sometimes there
>> are long discussion on Trac that I completely miss since they don't
>> happen on the mailing list. My question is how could we close this
>> gap?
>
> The Subversion project has a strict policy of closing tickets as invalid unless there is documentation of a discussion about the issue having already taken place on the mailing list and someone else having already agreed that it is an issue.
>
> MacPorts doesn't have such a strict policy, but I still think it makes sense to use the issue tracker for things that are unquestionably issues: obvious bugs, or enhancements that would obviously be nice. If you have any doubt about whether something is a bug in MacPorts, or anything else where discussion is in order, post to the mailing list first. If a ticket should be filed someone will surely say so.

Thanks for the clarification!

>> 2) Patch review? Sometimes I have questions on how to do a particular
>> task (i.e. best practice for "extracting" a script that isn't zipped?)
>> but can't figure it out by looking at other portfiles mostly due to
>> the fact that it's not commonly done. I could send an email to the dev
>> mailing list asking the quesetion, just commit the portfile and hope
>> that someone points out a better way, send a patch to the mailing
>> list, or submit a Trac ticket. Over the last year of so of lurking, I
>> haven't quite seen a uniform practice set, so any feedback is much
>> appreciated.
>
> Either is fine!
>
>
> On Jan 15, 2013, at 13:17, Sean Farley wrote:
>
>> On Tue, Jan 15, 2013 at 12:03 PM, Bradley Giesbrecht wrote:
>>>
>>> I do this a lot, adjusting the first grep with "-B" and "-A" flags: (in the example I am searching for where to install the AUTHORS file)
>>> $ echo $MP_SVNDPORTS
>>> /opt/local/var/macports/sources/svn.macports.org/trunk/dports
>>> $ find $MP_SVNDPORTS -maxdepth 3 -name Portfile -exec echo {} \; -exec grep -E -- "AUTHORS" {} \; | grep -B1 -v -E "/Portfile"
>>>
>>> This has worked for me for a long while, though I wouldn't mind something nicer. Maybe an sqlite registry query?
>>
>> For me, this command takes:
>>
>> $ time find $MP/dports -maxdepth 3 -name Portfile -exec echo {} \;
>> -exec grep -E -- "AUTHORS" {} \; | grep -B1 -v -E "/Portfile"
>>
>> real 1m2.393s
>> user 0m18.293s
>> sys 0m19.905s
>
> I really love my new Mac's SSD. Makes grepping all the portfiles much faster. It took several minutes on my old Mac. The above took 15s for me just now.

Huh. I have a ssd as well (a new macbook pro, actually) so I don't see
why it would be an order of magnitude faster for you. Odd. I wonder if
something's cached?

>> For csearch, it is a shorter command and takes:
>>
>> $ time csearch -f Portfile AUTHORS
>>
>> real 0m0.019s
>> user 0m0.010s
>> sys 0m0.006s
>
> How and when is the csearch index updated? I like that grep gets me completely up-to-date results every time.

It's manual but cindex updates itself in ~7s (depending on the number
of changed files) for me and is more than just macports (it's all my
code on my hard drive, in fact). I usually run it after pulling new
changes. But really, for me at least, code doesn't change fast enough
for me to care about hitting false-postives or whatnot; plus what I'm
usually searching for is an example so all I really want is the
location of a handful of files.

>>> Do you subscribe to these lists?
>>> macports-tickets at lists.macosforge.org
>>> macports-changes at lists.macosforge.org
>>
>> Fair enough. I initially wanted to keep my inbox volume low but I
>> guess there's no way around that :-(
>
> Once you're a committer, subscribing to macports-changes is highly recommended, if you have time to read the messages. It'll keep you in the loop about what's happening in MacPorts, and maybe teach you some new aspects of portfile writing.

That's true; I'll just bite the bullet and subscribe.