[Bioperl-l] Nightly build archives now available

[Chris Fields]

On Mar 7, 2008, at 11:34 AM, Sendu Bala wrote:

> Chris Fields wrote:
>> 1)  I am running a 'svn co' on anon. svn for the various distros to  
>> a temp directory.
>
> Is it important that you do a fresh co every night? Why not do a co  
> once   and then do a 'svn update' every night? This is the crux of  
> the problems: if you choose to simply update, then you only have to  
> get 'perl Build.PL' to work once.

Unless you update Build.PL (which will happen as the distributions  
grow).  Then you need to rerun 'perl Build.PL'.  It seems safer to run  
that each time with a 'pass-through' flag for automated builds.

>> If I attempt to change into the distribution directory and run  
>> 'perl Build.PL' from the bash script, I immediately run into  
>> permissions issues and several odd things:
>> Checking prerequisites...
>> - ERROR: Bio::Root::Version is not installed
>> (I think you ran Build.PL directly, so will use CPAN to install  
>> prerequisites on demand)
>> CPAN: Storable loaded ok
>> Going to read /root/.cpan/Metadata
>>  Database was generated on Tue, 05 Feb 2008 11:30:54 GMT
>> Warning: You are not allowed to write into directory "/root/.cpan/ 
>> sources/authors".
> [snip]
>
> I'm assuming this is on portal? The CPAN setup for users is a little  
> broken. You need to create /home/yourusername/.cpan/CPAN/MyConfig.pm
>
> $CPAN::Config->{cpan_home} = "/home/yourusername/.cpan/"
>
> Then you can run and configure cpan correctly and install  
> Bundle::CPAN. Some of the zlib stuff failed to install for me, but  
> that doesn't seem to matter.
>
> Of course, I guess it makes sense for root to just install all of  
> Bioperl's prereqs anyway, so that testing can be automated in the  
> future.
>
> Anyway, once you have cpan happy 'perl Build.PL' will run fine.  
> Answer 'n' to everything and then your cron job just has to call './ 
> Build dist'.

I agree about setting up the prereqs.  I could also (as mentioned  
before) set this up as root.  However, if we go this route we need to  
have 'perl Build.PL' included in the process in order to ensure a  
clean build process each time and to prevent the script from breaking  
whenever someone decides to change Build.PL.

>> 2) I suspect, even if I worked around permissions and set up the  
>> job as root or admin and worked out why it can't find  
>> 'Bio::Root::Version' (?!?), this would still be a terrific pain in  
>> the *** to deal with as the Build.PL process is expecting answers  
>> for each and every prompt, and the process differs for each  
>> distribution.
>
> You won't be running Build.PL in the cron job.

See above.  I don't want to set up something automated which can't be  
maintained in the long term.

>> passing flags to 'perl Build.PL' would be a nice way to work around  
>> that.  For that I haven't heard a response, so I assume that  
>> functionality isn't there (or am I assuming incorrectly?).
>
> It isn't AFAIK, but my point is that it doesn't need to be (for this  
> particular use-case at least).

See above.  There are very good reasons to allow this (and the  
functionality has been requested before, particularly from the GMOD  
crowd).  If I can pass in a single flag (for instance, --defaults,  
which just uses the default arg for each prompt) then it would make  
it /much/ easier.

>> So, from where I stand, even if using Build.PL is the /proper/ way  
>> to do it, it doesn't work as expected using an automated process  
>> (i.e. cron).  Make sense?
>
> Only if you can't run 'svn update' instead of 'svn co' each night.

I think a single co with updates is feasible (I can do that with the  
current setup; just run the initial co, copy the directory over to a  
temp copy, then go about my business).

I'll leave the nightly build setup as is for now and work on getting  
Build.PL working (something we need anyway for Devel::Cover and  
Pod::Coverage work).

chris