[123602] trunk/dports/python/py-astropy/Portfile

[Sean Farley]

Ryan Schmidt writes:

>> That sounds right. What I'm attempting to improve (or, rather, stir up
>> awareness) are the many steps that are manual. Being that stealth
>> updates are infrequent, I usually forgot to check for them. I think 
>> 
>> A workflow I am trying to strive for (which maybe should be another email):
>> 
>> Task: update outdated ports
>> 
>> $ port echo maintainer:sean | parallel --trim lr port livecheck {}
>> mercurial seems to have been updated (port version: 3.0, new version: 3.1)
>
> For this I use my portmylivecheck script:
>
> https://svn.macports.org/repository/macports/users/ryandesign/scripts/
>
>> $ port maintainerupdate mercurial
>>  # this would replace the previous version string with the new one and
>>  # accept the checksum changes
>
> For this I use my portcheckup script:
>
> https://svn.macports.org/repository/macports/users/ryandesign/scripts/

I have my own scripts (some based of yours) that help me but I would
suggest something more or less built-in (or at the very least installed
in /opt/local somewhere and easy to find).

I believe that would help us guide ticket reporters to take a more
active role in contributing patches.

>> $ hg ci -m "mercurial: update to 3.1"
>> $ hg push try-server
>
> If you're suggesting this just as a personal workflow for you, ok. But if you're suggesting this would be an infrastructure available to everyone, then we're either back at the old discussion of switching the MacPorts repository from Subversion to git or mercurial or something else, which we agreed before was too much effort, or we're talking about introducing a second version control system into the mix somehow, which sounds really confusing to me.

I mean more of a having a fleet of buildbot(-ish) servers to help
developers run a suite of tests. I personally do not have enough
machines to test every OS. I am willing to pay for some virtual private
servers but I think there would need to be some improvement of MacPorts
infrastructure to allow easy deploy on test machines.

>> # this is where a buildbot would test the change and tell me a few
>> # common issues:
>> #   - was there a stealth update
>
> We could perhaps enhance the buildbot scripts to re-fetch the upstream distfile every time you commit the port and to let you know if its checksums no longer match those in the portfile. But if so, only a human can determine if that was because of a stealth update or because of something else. It feels like this would be a waste of bandwidth and server resources, however.

This would at least save you the trouble of emailing the port author.

>> #   - did I "Use The Right Compiler"
>
> You can of course use the setup documented at the bottom of the UsingTheRightCompiler wiki page to determine this on your local machine prior to committing.

This is manual and therefore missed by some developers (including me
when I got a new machine).

> If you're wanting the buildbot to automate testing this for you, then I suppose instead of the current placeholder script that prints an error and exits (which can sometimes be missed because the output is discarded or hidden on a config.log or other log file), we could have the placeholder script create a log file of its own, followed by actually invoking the compiler so that the build succeeds anyway, then do something with the logfile later.

Yes, this would be a great addition. Having better output, in general,
would be helpful for tickets, too.

>> #   - run "port test" (or something similar)
>
> Yup, we've discussed previously that it would be nice if tests could be automatically run, however many ports' tests do currently fail, and some others take a very very very long time.

My hope would be for these failures to get better coverage (or in some
cases not tested, e.g. ATLAS).