Re: Best practice for releasing Perl modules to staging and live
On Mon, May 18, 2009 at 4:16 PM, Richard Huxton d...@archonet.com wrote: ian wrote: One company I worked at did just this for CPAN modules, but it was a many-day exercise to work out all the dependencies of (for example) Catalyst and to build them all into Debian packages. This is the bit that interests me. How do you find out... 1. What modules do I need to install/upgrade to install module M version V? 2. Given my currently installed set of modules, what is the latest version of module M that I can install? One gotcha I've stumbled upon here is the version numbers. Debian's system and CPAN's don't always mesh well. I believe it's possible to get a cpan version going from 1.39 to 1.4 but the debian stack would want the equivalent package to be 1.40. This isn't a common problem, and seems mostly confined to newer/more-obscure cpan dists. I use dpkg-buildpackage, which does a half decent job of parsing the CPAN package and using the various meta files to find stated dependencies. dpkg --compare-versions 0.3-0.9minty lt 0.3-0.10lt echo yes || echo no can help you figure out if debian thinks one version number is better than another.
Re: Best practice for releasing Perl modules to staging and live
On Tue, May 19, 2009 at 12:52 PM, Minty mintywal...@gmail.com wrote: I use dpkg-buildpackage For the record, here's my steps for building a new module from scratch. Aka, creating a deb for a cpan module that doesn't already exist. It isn't the same as building a deb for a module that exists already as a .deb and which you want a newer CPAN version. I don't claim to be an expert, or that these are good/right approaches, but they work for me (and took a lot of figuring out). They skip over steps that would be required to upload to an official debian/ubuntu repo, but they generate debs that can be installed with dpkg -i, or in my case, uploaded to a local apt repo, from where I then install them via apt[itude] install Using CPAN::Mini::Webserver here as an example is a bit evil, as it has a lot of dependencies that aren't in debian/ubuntu by default, you've been warned ;) C::M::W is most worth it once you've jumped through all the hoops tho. Caveats aside ... # Ensure minicpan is installed http://search.cpan.org/perldoc?minicpan # see also http://use.perl.org/~barbie/journal/38745 # Or, replace the next two steps with (a) find on search.cpan.org (b) download the tarball # Find the package/dist for the module you're after /bin/zgrep CPAN::Mini::Webserver ~/.MINICPAN/modules/02packages.details.txt # Unpack it /bin/tar zxvf ~/.MINICPAN/authors/id/L/LB/LBROCARD/CPAN-Mini-Webserver-0.45.tar.gz # Rename and duplicate it /bin/mv CPAN-Mini-Webserver-0.45 libcpan-mini-webserver-perl-0.45 /bin/cp -ai libcpan-mini-webserver-perl-0.45 libcpan-mini-webserver-perl-0.45.orig /bin/cp -ai libcpan-mini-webserver-perl-0.45 libcpan-mini-webserver-perl-0.45.test # dpkg-buildpackage wants the first two dirs, and (my wrapper script) # creates the latter for me to poke around and play in. # Namely... check it's not going to crash and burn when we try to build the deb cd libcpan-mini-webserver-perl-0.45.test perl Makefile.PL make make test This step normally reveals any issues. Lather, rinse repeat the above until you've got all the dependencies or issues resolved. Doing this for CPAN Mini Webserver was what motivated me to create my own wrapper script for all this, as I found myself lathering, rinsing and repeating a lot. # from the dir that *contains* libcpan-mini-webserver-perl* # magic all the debian meta files into existance /usr/bin/dh-make-perl libcpan-mini-webserver-perl-0.45 # Edit the change log vi libcpan-mini-webserver-perl-0.45/debian/changelog I use a template similar to this (between, not including the --- lines) -- libcpan-mini-webserver-perl (0.45-1~0minty) jaunty; urgency=low * Initial Release built from cpan bundle -- Minty mintywal...@gmail.com Tue, 19 May 2009 11:57:15 + -- # Now build your .deb cd libcpan-mini-webserver-perl-0.45 dpkg-buildpackage -rfakeroot -sa All being well, you should now have a .deb file in the parent dir. You can dpkg -i foo.deb to install this, or setup your own apt repo (another world of loads of docs, all slightly inconsistent and a lot of TIMTOWTDI setups from which you need to cherry pick what you want for your setup).
Re: Best practice for releasing Perl modules to staging and live
On Tue, May 19, 2009 at 1:21 PM, Minty mintywal...@gmail.com wrote: [ snip, see http://london.pm.org/pipermail/london.pm/Week-of-Mon-20090518/017176.html ] It isn't the same as building a deb for a module that exists already as a .deb and which you want a newer CPAN version. And here's what I do to upgrade from CPAN a deb that already exists # Find your tarball /bin/zgrep Template::Declare ~/.MINICPAN/modules/02packages.details.txt.gz # Get the exising deb /usr/bin/apt-get source libtemplate-declare-perl # Unbundle the newer cpan tarball /bin/tar zxvf ~/.MINICPAN/authors/id/A/AL/ALEXMV/Template-Declare-0.39.tar.gz # Rename dirs and create a .test dir for me to play in manually /bin/mv Template-Declare-0.39 libtemplate-declare-perl-0.39 /bin/cp -ai libtemplate-declare-perl-0.39 libtemplate-declare-perl-0.39.test # Apply any diffs/patches from the existing .deb file cd libtemplate-declare-perl-0.39 /bin/gzip -dc ../libtemplate-declare-perl*.diff.gz | patch -p1 Those patches are *generally* just the debian meta packaging files, but sometimes contain actual patches agains the code. Sometimes there are alternative packaging approaches to applying diffs. $hurt++ You need to get to the point where the diffs apply cleanly by hook or by crook # I need this, but I assume it's probably a sign I've got something wrong /bin/chmod u+x libtemplate-declare-perl-0.39/debian/rules # Update libtemplate-declare-perl-0.39/debian/changelog file # It should already exist, so use that as a reference. This next bit could be tackled in other ways -- but we're trying to get a sane libtemplate-declare-perl-0.39/debian/control # First, have dh-make-perl auto generate a debian/control file in our .test dir. # It uses the various cpan meta files to stab a wild guess in the dark /usr/bin/dh-make-perl libtemplate-declare-perl-0.39.test # Compare, contrast, manually merge vi -o2 libtemplate-declare-perl-0.39/debian/control libtemplate-declare-perl-0.39.test/debian/control # As before, manually check things aren't going to burn cd libtemplate-declare-perl-0.39.test perl Makefile.PL make make test Again, this normally shows up dependency issues. Lather, rinse, repeat ... again # Now build your deb cd libtemplate-declare-perl-0.39 dpkg-buildpackage -rfakeroot Note that we've not got -sa here which we did have when building a new .deb from scratch. You want the source included the first time you build a .deb, but subsequently you don't need it (in fact, i believe you actively don't want it). man dpkg-buildpackage
Re: Best practice for releasing Perl modules to staging and live
On Mon, May 18, 2009 at 4:29 PM, Dave Cross d...@dave.org.uk wrote: There will, of course, be a (hopefully far smaller) set of modules that aren't already packaged for your distribution. Once you've built those packages, you could consider sharing them with the rest of the world. Although once you start playing with Moose, Catalyst (and hit the repeated .. ahh, you're not using the latest version ... upgrade!) it's suprisingly easy to hit something that isn't in the latest Ubuntu dists. CPAN::Mini::Webserver also has a bucket load of deps that Ubuntu jaunty can't meet out of the box. In any event, ubuntu intrepid/jaunty should be able to get CPAN::Mini::Webserver installed from my apt repo, but ... CAVEAT: this exists for my use, and I do not claim it's safe, right or good. I believe it's all those things, but if it breaks your system, you get to keep all the pieces, etc. I can't honestly recommend you use this, but hey ... # /etc/apt/sources.list deb http://apt.sysmonblog.co.uk/ubuntu/ jaunty main deb-src http://apt.sysmonblog.co.uk/ubuntu/ jaunty main deb http://apt.sysmonblog.co.uk/ubuntu/ intrepid main deb-src http://apt.sysmonblog.co.uk/ubuntu/ intrepid main You can skip the next two steps if you want - when you try to install a deb from my apt repo, it'll shout scary insecure warnings at you, which frankly, is probably entirely sensible. # get a copy of (if you'd like it via some other secure channel, email me) http://sysmonblog.co.uk/misc/public_key.txt # Tell apt you trust my apt repo (you are a fool ... no really) sudo apt-key add apt.sysmonblog.co.uk_public.key sudo aptitude update sudo aptitude install libcpan-mini-webserver-perl minicpan_webserver And wait a few seconds while it indexes stuff, then follow it's instructions wrt the url. For me, it's http://localhost:8989/
Re: Best practice for releasing Perl modules to staging and live
Minty wrote: On Mon, May 18, 2009 at 4:29 PM, Dave Cross d...@dave.org.uk wrote: There will, of course, be a (hopefully far smaller) set of modules that aren't already packaged for your distribution. Once you've built those packages, you could consider sharing them with the rest of the world. Although once you start playing with Moose, Catalyst (and hit the repeated .. ahh, you're not using the latest version ... upgrade!) it's suprisingly easy to hit something that isn't in the latest Ubuntu dists. CPAN::Mini::Webserver also has a bucket load of deps that Ubuntu jaunty can't meet out of the box. [ snip ] My experience is in the Fedora/Centos world but, yes, it's easy to find things that are either a) missing or b) not the right version. I'm doing my bit tho' - http://rpm.mag-sol.com/ Cheers, Dave...
setting up a file hierarchy
Please help me do my homework :) I've got a module which creates .docx files. Those are Microsoft's latest Word format, as described in the OOXML standard. OOXML is not too gruesome to work with, and I'm having a great time stuffing my reports with figures and tables and whatnot. However, one very smelly piece of code is the creation of a new document. A .docx file is just a zip container with a handful of XML documents (plus extra media, if applicable). For most of these, the default content is fine. But what is the optimal way of generating them? I currently find myself doing a lot of mkdirs and print OUT EOFs, but that's messy. I could set up a template folder (next to the module?) and copy that around, but that feels awkward as well. I set up the hierarchy in a folder, and package that up with Archive::Zip, as it makes interactions with the files easier. I could write directly into a zip file, but that doesn't really make a difference to the problem. So. Any prior art? How should one treat non-code dependencies? (Note: I'm not bothered about deploying this stuff, this is for now strictly internal. Although, there doesn't seem to be _anything_ for OOXML on CPAN. Opportunity!) -- Jurgen Pletinckx ___ Vlaanderen mailing list vlaande...@pm.org http://mail.pm.org/mailman/listinfo/vlaanderen
cpan distribution for a pod file?
Dear lazyweb / perl elite, Given a real perl module, eg: Acme::Colour one can use Parse::CPAN::Packages (which uses 02packages.details.txt.gz) to determine which distribution that module belongs to. But 02packages.details.txt.gz doesn't contain .pod files, such as Catalyst::Manual::Intro afaik. Is it possible (with code) to determine which cpan distribution a pure pod file belongs to (and if so, how?) M.
Re: setting up a file hierarchy
On Tue, 19 May 2009 16:12:08 +0100, Dave Cross d...@dave.org.uk wrote: David Cantrell wrote: On Tue, May 19, 2009 at 04:02:19PM +0200, Jurgen Pletinckx wrote: So. Any prior art? How should one treat non-code dependencies? In a __DATA__ segment. If you need more than one file, bundle them up as blobs in a database in that segment, or put a zip/tarball there. Does anyone still use Inline::Files? http://search.cpan.org/dist/Inline-Files/ Dave... http://search.cpan.org/~adamk/File-ShareDir-1.00/lib/File/ShareDir.pm was created for this very purpose.
Re: setting up a file hierarchy
On Tue, May 19, 2009 at 04:22:29PM +0100, Ash Berlin wrote: http://search.cpan.org/~adamk/File-ShareDir-1.00/lib/File/ShareDir.pm was created for this very purpose. I'll pay attention when it doesn't rely on Module::Install. -- header FROM_DAVID_CANTRELLFrom =~ /david.cantrell/i describe FROM_DAVID_CANTRELLMessage is from David Cantrell scoreFROM_DAVID_CANTRELL15.72 # This figure from experimentation
Re: setting up a file hierarchy
On Tue, May 19, 2009 at 04:33:06PM +0100, David Cantrell wrote: I'll pay attention when it doesn't rely on Module::Install. Should I ask why? -- Chisel Wright e: chi...@herlpacker.co.uk w: http://www.herlpacker.co.uk/ I like to photograph people naked, but they usually ask me to get dressed again as it's not a pretty sight.
Re: [ANNOUNCE] Technical meeting: An evening of dynamic languages
Léon Brocard wrote: It's not very clear, but you need to sign up as a non-BCS member at the following URL first: https://wam.bcs.org/wam/RegisterNM.exe Not much of an advert for the BCS, is it? Dumb form tells me address line 1 is a required field, then won't allow me to type into it. I guess the clue is in the '.exe'. Or it may be in the scattered bits of php and javascript... Anyone else get past this (this is firefox 3.0.10)? Graham I just looked at it, considered it overly intrusive, and fired off an email of complaint to the BCS. Why are they asking for all this info? We are only wanting to attend a supposedly *public* meeting. I shall therefore not be at the meeting.
Re: setting up a file hierarchy
On Tue, May 19, 2009 at 04:50:06PM +0100, Chisel Wright wrote: On Tue, May 19, 2009 at 04:33:06PM +0100, David Cantrell wrote: I'll pay attention when it doesn't rely on Module::Install. Should I ask why? Would you like to install mandatory pre-requisite Foo::Bar for this 'ere module what you told the comptuer to install? Y/n Would you like to install mandatory pre-requisite Baz::Barf for this 'ere module what you told the comptuer to install? Y/n Would you like to install mandatory pre-requisite Quux::Garbleflux for this 'ere module what you told the comptuer to install? Y/n -- David Cantrell | http://www.cantrell.org.uk/david You are so cynical. And by cynical, of course, I mean correct. -- Kurt Starsinic
Re: setting up a file hierarchy
On Tue, May 19, 2009 at 04:02:19PM +0200, Jurgen Pletinckx wrote: A .docx file is just a zip container with a handful of XML documents (plus extra media, if applicable). For most of these, the default content is fine. But what is the optimal way of generating them? ... I set up the hierarchy in a folder, and package that up with Archive::Zip, as it makes interactions with the files easier. I could write directly into a zip file, but that doesn't really make a difference to the problem. I think I'd use Template Toolkit's ttree to build the internal structure, then package that with Archive::Zip as you suggest. That seems cleaner to me than a script with lots of END in it because the input file structure matches the output archive structure, but then I'm easily confused. Tom
Re: setting up a file hierarchy
On Tue, May 19, 2009 at 05:19:16PM +0100, David Cantrell wrote: On Tue, May 19, 2009 at 04:50:06PM +0100, Chisel Wright wrote: On Tue, May 19, 2009 at 04:33:06PM +0100, David Cantrell wrote: I'll pay attention when it doesn't rely on Module::Install. Should I ask why? Would you like to install mandatory pre-requisite Foo::Bar for this 'ere module what you told the comptuer to install? Y/n I think we're supposed to believe that everyone somehow knows to set the correct environment variable to deal with this. The environment variable exists, and it's documented. And we should all somehow find the right documentation, and if we consider it sufficiently annoying, patch the code or stop whining about backwards incompatibility. I worry about things like Modern Perl and Enlightened Perl, not because I want to remain stuck in the past, but because I worry about how we convey fundamental changes to Perl users outside our clique. Sometimes the word Schumpeter sounds like an elephant trampling everyone to death. Sorry, I don't have any constructive advice here other than that the constructive advice we offer should remain helpful in future, lest we eventualy alienate those we briefly appeal to. We've taught people how to use CPAN, then thrown away our credibility with Module::Install. Please replace the elephant, and grope it again. I feel fortunate to belong with the in-crowd that can ask the right people for help. Consequently, I've managed to make Module::Install behave how I want. People outside our clique won't know who to ask and won't readily get such helpful answers. Tom
Re: [ANNOUNCE] Technical meeting: An evening of dynamic languages
r...@mankin.org.uk wrote: I just looked at it, considered it overly intrusive, and fired off an email of complaint to the BCS. Why are they asking for all this info? We are only wanting to attend a supposedly *public* meeting. I shall therefore not be at the meeting. I follow the 'contact us' link to report a web problem, and ended up with a reply from a lady in BCS customer services who says I have to give them my phone number so they can ring me before I can be registered for the meeting. I have the impression they must be very concerned with physical security, and want anyone in their building to be traceable. Why, I have no idea. Are they a likely target for aggrieved clients of software companies? Graham
Re: setting up a file hierarchy
On 19 May 2009, at 17:19, David Cantrell wrote: On Tue, May 19, 2009 at 04:50:06PM +0100, Chisel Wright wrote: On Tue, May 19, 2009 at 04:33:06PM +0100, David Cantrell wrote: I'll pay attention when it doesn't rely on Module::Install. Should I ask why? Would you like to install mandatory pre-requisite Foo::Bar for this 'ere module what you told the comptuer to install? Y/n Would you like to install mandatory pre-requisite Baz::Barf for this 'ere module what you told the comptuer to install? Y/n Would you like to install mandatory pre-requisite Quux::Garbleflux for this 'ere module what you told the comptuer to install? Y/n -- David Cantrell | http://www.cantrell.org.uk/david You are so cynical. And by cynical, of course, I mean correct. -- Kurt Starsinic Your information is out of date. This no longer happens for new modules. If it does then complain at that module author to upgrade his dist. Or at Alias to make Module::Install fucking well self update. Also File::ShareDir doesn't rely on Module::Install at all - Module::Install just gives you an way to install the files in the 'right' place. Module::Build can easily do it to. Since everyone is lazy http://cpansearch.perl.org/src/ADAMK/Module-Install-0.88/lib/Module/Install/Share.pm
Re: short term accommodation
Hi all, So it looks like I'm going to be London for a few months working at the beeb. I'm not too familiar with london geography, but I'm looking for places to stay/share/whatever that's a short commute to white city. Does anyone have a spare room, know of folks with a spare room or have any other advice in terms of accommodation? thanks! -- -Scott McWhirter- | -Technology Consultant- [ Cloudtone Studios - http://www.cloudtone.ca ]
Re: [ANNOUNCE] Technical meeting: An evening of dynamic languages
On 19 May 2009, at 18:25, Graham Seaman wrote: I follow the 'contact us' link to report a web problem, and ended up with a reply from a lady in BCS customer services who says I have to give them my phone number so they can ring me before I can be registered for the meeting. I have the impression they must be very concerned with physical security, and want anyone in their building to be traceable. Why, I have no idea. Are they a likely target for aggrieved clients of software companies? Perhaps they're afraid anyone who has used their website might attend. --James, who will also not be in attendance because their website sucks.
Re: [ANNOUNCE] Technical meeting: An evening of dynamic languages
i agree that they are asking too much info, but i registered anyway... On Tue, May 19, 2009 at 7:50 PM, James Laver james.la...@gmail.com wrote: On 19 May 2009, at 18:25, Graham Seaman wrote: I follow the 'contact us' link to report a web problem, and ended up with a reply from a lady in BCS customer services who says I have to give them my phone number so they can ring me before I can be registered for the meeting. I have the impression they must be very concerned with physical security, and want anyone in their building to be traceable. Why, I have no idea. Are they a likely target for aggrieved clients of software companies? Perhaps they're afraid anyone who has used their website might attend. --James, who will also not be in attendance because their website sucks. -- http://evolectronica.com - survival of the funkiest
Re: Best practice for releasing Perl modules to staging and live
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Minty wrote: On Tue, May 19, 2009 at 12:52 PM, Minty mintywal...@gmail.com wrote: I use dpkg-buildpackage For the record, here's my steps for building a new module from scratch. Aka, creating a deb for a cpan module that doesn't already exist. It isn't the same as building a deb for a module that exists already as a .deb and which you want a newer CPAN version. There's also: dh-make-perl --build --cpan Foo::Bar which gets most things right but can fall down on the dependencies. In my experience the maintainers have a helpful IRC channel (#debian-perl ?) and are free with commit bits if you have patches. For many Perl Debian packages you can often rebuild the bleeding edge version for your current dist release quite easily: http://packages.debian.org/libfoo-bar-perl - -- Oliver Gorwits, Network and Telecommunications Group, Oxford University Computing Services -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKEw+r2NPq7pwWBt4RAgkiAKCiD/p41e5NwJ7pvS5BfDwRsw90agCeOSD1 NZ8AuIPwezxEmLY8Bb/FqSM= =Bksx -END PGP SIGNATURE-
Re: Best practice for releasing Perl modules to staging and live
On May 19, 2009, at 7:22, Paul Johnson wrote: The way I do this is to build perl and all the modules I need on the development machine. Then I package up the whole lot as a single package. The big failure in this is that you can only have one version of stuff. One developer experimentally wants to try a new version of Foo::Bar? Too bad. Want to deploy two versions of your app on the same box (prod/stage running as different users). Too bad. One developer debugging an older version of the application that a partner is using? Too bad. Perl modules are part of your application; not of the system. - ask
