.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/31beb504-c72b-4304-95ba-a66d2bcbc46a/body

   1 On Tue, Jul 14, 2009 at 07:34:04PM +0100, jnrowe@gmail.com wrote:
   2 > [This time to the list]
   3 >
   4 > * W. Trevor King (wking@drexel.edu) wrote:
   5 > > On Tue, Jul 14, 2009 at 03:29:42PM +0100, James Rowe wrote:
   6 > > >   Isn't there a bzr web interface that at least supports creating
   7 > > > tarballs/zips?  It is pretty standard functionality for most other VCS'
   8 > > > web interfaces so I'm guessing there must be, but loggerhead seems not
   9 > > > to support it.
  10 > >
  11 > > Unfortunately, people would still need bzr to install the versioned source:
  12 > >
  13 > >   libbe/_version.py:
  14 > >           bzr version-info --format python > $@
  15 >
  16 >   I hadn't even seen that change go in.  The last upstream change in the
  17 > version I have installed locally was by you on 2008-11-24.
  18
  19 It's only been in Chris' http://bzr.bugseverywhere.org/be/ branch
  20 since revno: 321, 2009-06-25.  Obviously we may have to adjust the
  21 --verison output once we settle on a versioning scheme, but whatever
  22 we pick, I think having the auto-generated libbe/_version.py around
  23 for pinpointing bugs is worth the trouble of requiring bzr when
  24 building distribution tarballs.
  25
  26 > > So you'll need a "release" target in the makefile to build a bzr-less
  27 > > install.  While you're at it, you should probably compile the manpage
  28 > > too to remove the docbook-to-man dependency.
  29 >
  30 >   Maybe for others.  Our packages just don't have the manpage as it is only
  31 > the "be help" text reformatted, the easy option is sometimes the right
  32 > one :)  Also, I've just noticed that it has even less documentation in
  33 > the bzr tree[1] making its installation much less compelling unless your
  34 > packaging rules require a man page like Debians.
  35 >
  36 >   Out of curiosity why is the Makefile being used for this stuff anyway?
  37 > It is going to make it difficult to build locally when we finally get
  38 > around to merging.  Examples: If distutils was being used exclusively it
  39 > would fix the #! lines in xml/*.  We'd be able to point Python
  40 > $version_of_the_day at setup.py instead of having to sed the Makefile or
  41 > run setup and manually install other files.
  42
  43 I speak Makefile better than I speak distutils ;).  I'm not sure how
  44 to translate the be.1 generation/installation or the libbe/_version.py
  45 generation into distutils.  Anyone else?
  46
  47 --
  48 This email may be signed or encrypted with GPG (http://www.gnupg.org).
  49 The GPG signature (if present) will be attached as 'signature.asc'.
  50 For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
  51
  52 My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt