Re: ${PYPKGPREFIX}- for package names (and wip/py-buildbot)

["Oliver V. Gould" <ver%olix0r.net@localhost>]

On 2009-07-09, Jeremy C. Reed <reed%reedmedia.net@localhost> wrote:
> On Thu, 9 Jul 2009, Oliver V. Gould wrote:
>
>> On 2009-06-30, Jeremy C. Reed <reed%reedmedia.net@localhost> wrote:

>> It seems perfectly reasonable for me to install both py25-buildbot
>> and py26-buildbot on the same host (for instance, to run buildbots
>> that test for backwards compatibility with python versions).
>
> I am not sure I understand the need for different buildbots for that 
> testing. Seems like a new buildbot can be used to "test" old versions. 

Yes, you are right that this was probably a bad example.  And now that I
think about it, there's no good reason to need to *run* py25-buildbot
and py26-buildbot on the same host.

However, because this package does install library code and we cannot
dictate how these libraries will be used or extended by other
libraries and applications -- which may have a very legitimate need to
support multiple python-versions -- I think that this requirement
stands.

So why might a module need to support multiple python versions on one
system?  Consider this contrived example:
- My DEFAULT_PYTHON_VERSION is python2.6
- I build py-buildbot (as py26-buildbot)
- There is some software, py-blah, which depends on py-buildbot
- py-blah isn't really that actively maintained so py25-blah builds but
  py26-blah does not.
- I should still be able to install py25-blah which depends on
  py25-buildbot regardless of the fact that I have py26-buildbot
  installed.

>> This should dictate that that the buildbot executable is installed as
>> e.g. buildbot2.5 and buildbot2.6.
>
> That's misleading since makes it look like the Buildbot version is 
> 2.5 or 2.6 when really is "0.7.10p1" or similar. Maybe py25-buildbot or 
> py26-buildbot as executable name. Then would have to put info files and 
> other non "site-packages" as versioned filenames (or directories).

Yeah, this is undoubtedly a bit messy.  Consider py-twisted, however,
which installs twistd(1) (among other executables).  It should
definitely be possible to have py25-twisted and py26-twisted on one
host.

I'm curious how other package managers have dealt with this.  In my
experience, I've seen it done Wrong (where executables overwrite each
other) or Half-Wrong (where these packages conflict).  At a first
estimation, it seems to me that meta-packages may be a sufficient
mechanism to install e.g. bin/buildbot (as a symlink to the
python-version-specific executable).

>> FWIW, I have written code that doesn't use the buildbot executable but
>> extends the buildbot module, so this module in particular is very much
>> an interface in my mind.  Though, I think this principal should probably
>> apply to ~all Python packages.
>
> What do you use the buildbot module for?

The code isn't open (yet), but...

I disliked the need to have a very large master.cfg to build for
multiple components (admittedly something buildbot claims not to do
well).  So, I leveraged twisted.python.plugin to implement a plugin
framework for installable build and slave specifications.  Also I
specialized various things for our corporate environment.

I had plans to extend the LatentBuildSlave (or some such?) class to
start/stop VMWare guests as needed, but I have had neither the time nor
the demand to get around to this.

> I am working on the buildbot package and hope to import to pkgsrc
> proper (from wip) but it has many failed tests. By the way, I have a
> buildbot build slaves on NetBSD for the buildbot and twisted projects
> that show that the build slave works but also show that many "tests"
> fail.

Unfortunately I've only had very limited use of buildbot on NetBSD
(though I'm looking to change that).  Most of my experience has been
with RHEL and FreeBSD. If such a comparison would be useful, I can
probably checkout WIP onto these environments and see how the buildbot
trials fare.

Hope this sheds some more light on where I'm coming from.  If not, let
me know ;)

  - Oliver