[Systers-dev] Additional Development Server

[Jennifer Redman]

Queue classic Sys Admin (me) vs Developer (Gloria) system setup argument ;>.

On Tue, Mar 30, 2010 at 1:03 PM, Gloria W <strangest at comcast.net> wrote:

>
>
>>
>>
> true, but IMHO, and from first-hand experienc,e it is a royal pain to use
> debian to manage this. For example, if you install another version of Python
> and configure Debian to use it as the unsupported default, it will _still_
> replace it with Python 2.5 if other python-dependent OS tools are installed
> (such as denyhosts).
>

While we have some more wiggle room with this server -- because it is a
development box, it still needs to be as close as possible to the
testing/production servers.  We want to use the default Python for
everything except possibly some experimental development branches.   GNU
Mailman is not installed via the package system so it should be fairly
simple to change the python path via environmental variables - but this
should not be a system-wide change, nor should it effect any software
outside of GNU mailman.  The number 1 goal is system stability, and
controlled deviation from the production configurations to prevent the
introduction of random bugs and config problems.



>
> So I recommend this fool-proof way of installing different versions of
> Python. It is the old-timer, "AT&T" way, which has never failed, and is
> mutually exclusive of any OS dependencies.
>
> Build and install Python 3.X in /usr/local/python/3.X (very easy if you
> download the source, and pass the "--prefix=/usr/local/python/3.X" to the
> "configure" command).
>
> Set every developer's .bash_profile to prepend /usr/local/python/3.X/bin to
> the PATH variable (I am afraid to do this in .bashrc, because it can run
> multiple times per session, meaning your path may grow indefinitely. The
> trade-off is that you have to make sure the .bash_profile is executed when
> people log in, which is not always the case in bash. This is usually done in
> the master /etc/profile, for all users other than root).
>

This means that we need to teach students et.al. how to manage their shells,
which is fine -- any volunteers to type up a Bash tutorial for the wiki?
 Again for the above-mentioned reasons we don't want to change global
variables.  AND it's important to make sure any version of Python that we
are using for development is compatible with MM 3.0 or Systers Production.
 At this point I haven't seen any indication that developing against Python
3.0 is a good idea with regards to system stability and backwards
compatibility.  Remember we are currently running MM 2.10 which doesn't work
so great with the jump from Python 2.5 to 2.6.

That being said -- I think it's a great idea to explore our options with
regards to Python 3.0 with the various projects.  I recommend getting in
touch with Barry W. to see what his thoughts are re: Python 3 and MM 3.0.
 Terri O. might have some input here as well.


>
> Do we want to apply this to the dev image?
>

Apply what?  I believe the dev image needs to be exactly as is right now --
a copy of Systers production, but I'd encourage people to make other images
that students could load up.  The beauty of Virtual Box is that it is
possible to have multiple VMs.

Jenl