Our solution consists of:
* our own base python distribution, decoupled from the OS one (for
various reasons, one being version independency)
* distutils / setuptools / virtualenv is included in that python
installation, no other eggs installed in site-packages
* virtualenv + Paver to manage bui
Diez B. Roggisch wrote:
>> that is a very valid point, but it seemed that Scott has homogeneous
>> environment: Debian/Ubuntu so my post was relative to the original
>> request.
>> I agree that when you throw Windows/MacOS into the mix things
>> become "interesting". But then it's better when your
Diez B. Roggisch wrote:
> Well, you certainly want a desktop-orientied Linux for users, so you
> chose ubuntu - but then on the server you go with a more stable debian
> system. Even though the both have the same technical and even package
> management-base, they are still incompatible wrt to packa
that is a very valid point, but it seemed that Scott has homogeneous
environment: Debian/Ubuntu so my post was relative to the original request.
I agree that when you throw Windows/MacOS into the mix things
become "interesting". But then it's better when your developers develop on
server/platform
Diez B. Roggisch wrote:
> - different OS. I for one don't know about a package management tool
> for windows. And while our servers use Linux (and I as developer as
> well), all the rest of our people use windows. No use telling them to
> apt-get instal python-imaging.
that is a very valid poin
Diez B. Roggisch wrote:
> Dmitry S. Makovey schrieb:
>> Scott Sharkey wrote:
>>> Any insight into the best way to have a consistent, repeatable,
>>> controllable development and production environment would be much
>>> appreciated.
>>
>> you have just described OS package building ;)
Except that
Dmitry S. Makovey schrieb:
Scott Sharkey wrote:
Any insight into the best way to have a consistent, repeatable,
controllable development and production environment would be much
appreciated.
you have just described OS package building ;)
I can't speak for everybody, but supporting multiple pl
Nick Craig-Wood schrieb:
Scott Sharkey <[EMAIL PROTECTED]> wrote:
B> Our development group at work seems to be heading towards adopting
python as one of our standard "systems languages" for internal
application development (yeah!). One of the issues that's come up is
the problem with apt
Scott Sharkey <[EMAIL PROTECTED]> wrote:
B> Our development group at work seems to be heading towards adopting
> python as one of our standard "systems languages" for internal
> application development (yeah!). One of the issues that's come up is
> the problem with apt (deb packages) vs egg
Scott Sharkey schrieb:
Hello all,
Our development group at work seems to be heading towards adopting
python as one of our standard "systems languages" for internal
application development (yeah!). One of the issues that's come up is
the problem with apt (deb packages) vs eggs, vs virtual env
Dmitry S. Makovey wrote:
you have just described OS package building ;)
I can't speak for everybody, but supporting multiple platforms (PHP, Perl,
Python, Java) we found that the only way to stay consistent is to use OS
native packaging tools (in your case apt and .deb ) and if you're missing
s
Scott Sharkey wrote:
> Any insight into the best way to have a consistent, repeatable,
> controllable development and production environment would be much
> appreciated.
you have just described OS package building ;)
I can't speak for everybody, but supporting multiple platforms (PHP, Perl,
Pytho
Hello all,
Our development group at work seems to be heading towards adopting
python as one of our standard "systems languages" for internal
application development (yeah!). One of the issues that's come up is
the problem with apt (deb packages) vs eggs, vs virtual environments.
We're probab
13 matches
Mail list logo
