[Reportbug-maint] Deployment of reportbug for development work (was: merging common stuff in python-debianbts?)

[Ben Finney]

[replying back on reportbug-maint, I presume that was your intent 
Chris]

On 06-Jun-2008, Chris Lawrence wrote:
> On Thu, Jun 5, 2008 at 6:26 PM, Ben Finney <ben at benfinney.id.au> wrote:
> > I'm planning to implement the 'reportbug' Python package, by 
> > moving the 'reportbug' program to a separate directory to avoid 
> > that name conflict. I think that the expected package name for 
> > reportbug modules will be the name 'reportbug', so it's worth 
> > choosing that name if possible.
> 
> I really don't care that much about the name; the only issue with
> moving the scripts to bin (or anywhere outside of the root) is it
> makes it a pain in the ass to do in-place testing of reportbug.

This is a valid concern.

The import system of Python forces developers, when using package 
directories, to deal with the deployment of mid-development packages 
so they can be tested.

With Python's 'distutils', one can install a Python "distribution" to 
an arbitrary location; with appropriate PYTHONPATH environment 
variable setting, one can thus deply the software to a private 
location that doesn't affect the system-controlled locations.

The 'setuptools' system goes a step further to provide a solution to 
this: deploying the package locally in "development mode" in order to 
immediately use the latest code, but only linking back to the working 
tree instead of copying the software anywhere.

    To do this, use the setup.py develop command. It works very 
    similarly to setup.py install or the EasyInstall tool, except that 
    it doesn't actually install anything. Instead, it creates a 
    special .egg-link file in the deployment directory, that links to 
    your project's source code. And, if your deployment directory is 
    Python's site-packages directory, it will also update the 
    easy-install.pth file to include your project's source code, 
    thereby making it available on sys.path for all programs using 
    that Python installation.

    In addition, the develop command creates wrapper scripts in the 
    target script directory that will run your in-development scripts 
    after ensuring that all your install_requires packages are 
    available on sys.path.

    You can deploy the same project to multiple staging areas, e.g. if 
    you have multiple projects on the same machine that are sharing 
    the same project you're doing development work.

    When you're done with a given development task, you can remove the 
    project source from a staging area using setup.py develop 
    --uninstall, specifying the desired staging area if it's not the 
    default.

    <URL:http://peak.telecommunity.com/DevCenter/setuptools#development-mode>

I can work on converting 'reportbug' to use 'distutils' (to allow 
manual deployment to be done more easily), or 'setuptools' (to allow 
the above "development mode"). Which would we prefer?

-- 
 \     "I wrote a song, but I can't read music so I don't know what it |
  `\    is. Every once in a while I'll be listening to the radio and I |
_o__)     say, 'I think I might have written that.'"  -- Steven Wright |
Ben Finney <ben at benfinney.id.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/reportbug-maint/attachments/20080607/78faa9ba/attachment.pgp