[Distutils] stdeb-0.3 error
sudo easy_install stdeb # brought in stdeb 0.3
$ cd myappdir # where my setup.py is located
$# following http://github.com/astraw/stdeb/ quickstart 1
$ python -c "import stdeb; execfile('setup.py')" sdist_dsc && \
> cd `find deb_dist -mindepth 1 -maxdepth 1 -type d` && \
> dpkg-buildpackage -rfakeroot -uc -us && \
> cd ../.. &&
> echo ".deb created successfully in deb_dist/"
Traceback (most recent call last):
File "", line 1, in
File "setup.py", line 41, in
sys.path.append(os.path.join(os.path.abspath(os.path.dirname(__file__)),
"bin"))
NameError: name '__file__' is not defined
=
The error is coming from the setup.py line:
import imp
import sys
import os
import glob
from distutils.core import setup, Command
from distutils.command.install import install
if os.name == 'nt':
import py2exe
sys.path.append(os.path.join(os.path.abspath(os.path.dirname(__file__)),
"bin"))
===
I do not get this error when I run setup.py normally for other commands
like 'sdist'.
How can I fix this?
Regards,
Gerry
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote:
> sudo easy_install stdeb # brought in stdeb 0.3
>
> $ cd myappdir # where my setup.py is located
>
> $# following http://github.com/astraw/stdeb/ quickstart 1
>
> $ python -c "import stdeb; execfile('setup.py')" sdist_dsc && \
> > cd `find deb_dist -mindepth 1 -maxdepth 1 -type d` && \
> > dpkg-buildpackage -rfakeroot -uc -us && \
> > cd ../.. &&
> > echo ".deb created successfully in deb_dist/"
> Traceback (most recent call last):
> File "", line 1, in
> File "setup.py", line 41, in
>
> sys.path.append(os.path.join(os.path.abspath(os.path.dirname(__file__)),
> "bin"))
> NameError: name '__file__' is not defined
You can use something more elaborate like
python -c "import
stdeb,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
sdist_dsc
for the first line.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote:
> Ok, I got the __file__ problem solved but now I want to do this whole
> deb pkg create as just a single command in my own setup.py. How can I
> do this?
>
> I'm thinking something like:
>
> # my setup.py
> import stdeb
>
> Command(mycmd):
>initialize_option...
>finalize_option...
>run
> sub_commands=[('sdist_dsc', None),]
> system('dpgk-source ...)
> print ".deb is here..."
>
> Would this work and is this how to do it?
Do you really need to run it directly from setup.py? Can't you run it
from a shell script or write a python script making lots of use of
subprocess? The reason I ask is that distutils isn't fun to extend, and
as you're already going to be running on a Debian-based system, I can't
see what's to be gained.
What you want to do is probably possible, but I don't have the
motivation to do it myself. I guess it could allow a bdist_deb option,
but IMO that's not particularly desirable -- the Debian source package
emitted by stdeb can be compiled for any Debian derivative for any
version (provided the dependencies are met) -- whereas the .deb will
only have defined behavior on the Debian/Ubuntu release on which it was
built.
-Andrew
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Ok, I got the __file__ problem solved but now I want to do this whole
deb pkg create as just a single command in my own setup.py. How can I
do this?
I'm thinking something like:
# my setup.py
import stdeb
Command(mycmd):
initialize_option...
finalize_option...
run
sub_commands=[('sdist_dsc', None),]
system('dpgk-source ...)
print ".deb is here..."
Would this work and is this how to do it?
Regards,
Gerry
Andrew Straw wrote:
Gerry Reno wrote:
sudo easy_install stdeb # brought in stdeb 0.3
$ cd myappdir # where my setup.py is located
$# following http://github.com/astraw/stdeb/ quickstart 1
$ python -c "import stdeb; execfile('setup.py')" sdist_dsc && \
cd `find deb_dist -mindepth 1 -maxdepth 1 -type d` && \
dpkg-buildpackage -rfakeroot -uc -us && \
cd ../.. &&
echo ".deb created successfully in deb_dist/"
Traceback (most recent call last):
File "", line 1, in
File "setup.py", line 41, in
sys.path.append(os.path.join(os.path.abspath(os.path.dirname(__file__)),
"bin"))
NameError: name '__file__' is not defined
You can use something more elaborate like
python -c "import
stdeb,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
sdist_dsc
for the first line.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote: >> What you want to do is probably possible, but I don't have the >> motivation to do it myself. I guess it could allow a bdist_deb option, >> but IMO that's not particularly desirable -- the Debian source package >> emitted by stdeb can be compiled for any Debian derivative for any >> version (provided the dependencies are met) > Having a single command for .deb doesn't preclude stdeb from emitting > source package .dsc. OK, if you're sure... :) I'd suggest attempting to add a "bdist_deb" command to stdeb's stdeb/command/ directory for use with distutils. Then register it with entry_points in the setup.py file. Note that you wouldn't want bdist_deb to inherit the binary generation stuff from bdist_dumb or friends -- you'd specifically want to call out the the appropriate debian command (dpkg-buildpackage). I'd be happy to include such a thing with stdeb, though I'd probably not use it much myself -- I like having a single source package that I just recompile for the different distributions. -Andrew ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Andrew Straw wrote:
Gerry Reno wrote:
Ok, I got the __file__ problem solved but now I want to do this whole
deb pkg create as just a single command in my own setup.py. How can I
do this?
I'm thinking something like:
# my setup.py
import stdeb
Command(mycmd):
initialize_option...
finalize_option...
run
sub_commands=[('sdist_dsc', None),]
system('dpgk-source ...)
print ".deb is here..."
Would this work and is this how to do it?
Do you really need to run it directly from setup.py?
Yes.
Can't you run it
from a shell script or write a python script making lots of use of
subprocess? The reason I ask is that distutils isn't fun to extend, and
as you're already going to be running on a Debian-based system, I can't
see what's to be gained.
What you want to do is probably possible, but I don't have the
motivation to do it myself. I guess it could allow a bdist_deb option,
but IMO that's not particularly desirable -- the Debian source package
emitted by stdeb can be compiled for any Debian derivative for any
version (provided the dependencies are met)
Having a single command for .deb doesn't preclude stdeb from emitting
source package .dsc.
-- whereas the .deb will
only have defined behavior on the Debian/Ubuntu release on which it was
built.
Well of course, just like any other binary package target.
I don't see where there is any conflict.
Regards,
Gerry
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Andrew Straw wrote: Gerry Reno wrote: What you want to do is probably possible, but I don't have the motivation to do it myself. I guess it could allow a bdist_deb option, but IMO that's not particularly desirable -- the Debian source package emitted by stdeb can be compiled for any Debian derivative for any version (provided the dependencies are met) Having a single command for .deb doesn't preclude stdeb from emitting source package .dsc. OK, if you're sure... :) I'd suggest attempting to add a "bdist_deb" command to stdeb's stdeb/command/ directory for use with distutils. Then register it with entry_points in the setup.py file. Note that you wouldn't want bdist_deb to inherit the binary generation stuff from bdist_dumb or friends -- you'd specifically want to call out the the appropriate debian command (dpkg-buildpackage). I'd be happy to include such a thing with stdeb, though I'd probably not use it much myself -- I like having a single source package that I just recompile for the different distributions. Well, I think it would be better if it were part of stdeb. And I like calling it 'bdist_deb'. That makes sense. And it should emit the .dsc as well as the .deb. My use case is providing consumers of my apps with a way to gen their own source and binary packages without them needing to know anything about the "mechanics" of the process. I've already got good feedback on this with 'bdist_rpm' and if we had 'bdist_deb' then that would add a good deal more capability. For bdist_rpm we drive it from setup.cfg and would be good if bdist_deb configuration behavior would be the same. Regards, Gerry ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Ok, I have a setup.py that imports stdeb and creates a 'bdist_deb' command.
The entire thing is working except for the last subcommand for
dpkg-buildpackage is trying to build for python2.4 and failing.
dpkg-buildpackage fails in the fakeroot...
...
debian/rules build
python2.4 -c "import
setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
build
Traceback (most recent call last):
File "", line 1, in ?
File "setup.py", line 35, in ?
import stdeb
ImportError: No module named stdeb
make: *** [build-python2.4] Error 1
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
Is this something to do with python versions?
So how do I limit the python versions for dpkg-buildpackage?
stdeb is 0.3
$ python -V
Python 2.5.2
Regards,
Gerry
Gerry Reno wrote:
Ok, I got the __file__ problem solved but now I want to do this whole
deb pkg create as just a single command in my own setup.py. How can I
do this?
I'm thinking something like:
# my setup.py
import stdeb
Command(mycmd):
initialize_option...
finalize_option...
run
sub_commands=[('sdist_dsc', None),]
system('dpgk-source ...)
print ".deb is here..."
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote:
> Ok, I have a setup.py that imports stdeb and creates a 'bdist_deb'
> command.
Great.
> The entire thing is working except for the last subcommand for
> dpkg-buildpackage is trying to build for python2.4 and failing.
>
> dpkg-buildpackage fails in the fakeroot...
> ...
> debian/rules build
> python2.4 -c "import
> setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
> build
> Traceback (most recent call last):
> File "", line 1, in ?
> File "setup.py", line 35, in ?
> import stdeb
> ImportError: No module named stdeb
> make: *** [build-python2.4] Error 1
> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
>
> Is this something to do with python versions?
> So how do I limit the python versions for dpkg-buildpackage?
To answer your question directly[*]:
create an stdeb.cfg file like the following and put in the
distribution_name.egg-info directory. (See "Customizing the produced
Debian source package" at http://github.com/astraw/stdeb ).
[default]
XS-Python-Version: 2.5
[*] Note: I think if you switch to stdeb 0.4 you won't need stdeb
installed for all Python versions to run debian/rules. There is a much
cleaner infrastructure making use of debhelper 7. At this point, I
suggest downloading the 0.4 branch and working from there. I don't think
any of your changes so far will be hard to port, but working on
modifying debian/rules in the 0.3 branch doesn't have much of a future.
If you're not a git person, you can simply download the latest version
of the master branch by clicking the "download" button at
http://github.com/astraw/stdeb (not the "Downloads" tab). I hope with
stdeb 0.4 this won't be necessary.
-Andrew
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Ok, I found how to control the python version: XS-Python-Version
So now it is using python2.5 but dpkg-buildpackage hits an error:
error: option --single-version-externally-managed not recognized
What is this option?
I've been searching but I don't find how to solve this.
Is there a way to fix this?
Regards,
Gerry
Gerry Reno wrote:
Ok, I have a setup.py that imports stdeb and creates a 'bdist_deb'
command.
The entire thing is working except for the last subcommand for
dpkg-buildpackage is trying to build for python2.4 and failing.
dpkg-buildpackage fails in the fakeroot...
...
debian/rules build
python2.4 -c "import
setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
build
Traceback (most recent call last):
File "", line 1, in ?
File "setup.py", line 35, in ?
import stdeb
ImportError: No module named stdeb
make: *** [build-python2.4] Error 1
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
Is this something to do with python versions?
So how do I limit the python versions for dpkg-buildpackage?
stdeb is 0.3
$ python -V
Python 2.5.2
Regards,
Gerry
Gerry Reno wrote:
Ok, I got the __file__ problem solved but now I want to do this whole
deb pkg create as just a single command in my own setup.py. How can I
do this?
I'm thinking something like:
# my setup.py
import stdeb
Command(mycmd):
initialize_option...
finalize_option...
run
sub_commands=[('sdist_dsc', None),]
system('dpgk-source ...)
print ".deb is here..."
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote: > In my setup.py I have my own "install": > > from distutils.command.install import install > ... > class myinstall(install): > ... > > and when we call dpkg-buildpackage this local "install" seems to maybe > be causing the problem with the error: option > --single-version-externally-managed not recognized. > > How can we make this option be recognized? Do we need to inherit > something from setuptools? I think there are 2 options: 1) upgrade to the nascent stdeb 0.4. It doesn't call setup.py with the --single-version-externally-managed argument. 2) inherit from setuptools' install command. I would suggest option 1. If you need me to make a release, I'm happy to do so -- but maybe that will be better after it has bdist_deb? :) -Andrew ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Andrew Straw wrote: Gerry Reno wrote: In my setup.py I have my own "install": from distutils.command.install import install ... class myinstall(install): ... and when we call dpkg-buildpackage this local "install" seems to maybe be causing the problem with the error: option --single-version-externally-managed not recognized. How can we make this option be recognized? Do we need to inherit something from setuptools? I think there are 2 options: 1) upgrade to the nascent stdeb 0.4. It doesn't call setup.py with the --single-version-externally-managed argument. I'm using Ubuntu 8.0.4 LTS Server and when I run apt-get it brings in stdeb 0.3. I always use the distro packagers to install software so how can I use apt-get to install stdeb 0.4? 2) inherit from setuptools' install command. I don't like that idea. That may mean a lot of rework as it took a while to get our "install" all debugged and working. I would suggest option 1. If you need me to make a release, I'm happy to do so -- but maybe that will be better after it has bdist_deb? :) My only concern now with stdeb adding the bdist_deb command is that it may not work like other 'bdist' commands. And having 'bdist_deb' work similar to 'bdist_rpm' is important. It would have to use setup.cfg for config and allow for pre/postinstall scripts to run. Regards, Gerry ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
In my setup.py I have my own "install":
from distutils.command.install import install
...
class myinstall(install):
...
and when we call dpkg-buildpackage this local "install" seems to maybe
be causing the problem with the error: option
--single-version-externally-managed not recognized.
How can we make this option be recognized? Do we need to inherit
something from setuptools?
Regards,
Gerry
Gerry Reno wrote:
Ok, I found how to control the python version: XS-Python-Version
So now it is using python2.5 but dpkg-buildpackage hits an error:
error: option --single-version-externally-managed not recognized
What is this option?
I've been searching but I don't find how to solve this.
Is there a way to fix this?
Regards,
Gerry
Gerry Reno wrote:
Ok, I have a setup.py that imports stdeb and creates a 'bdist_deb'
command.
The entire thing is working except for the last subcommand for
dpkg-buildpackage is trying to build for python2.4 and failing.
dpkg-buildpackage fails in the fakeroot...
...
debian/rules build
python2.4 -c "import
setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'__file__':f,'__name__':'__main__'})"
build
Traceback (most recent call last):
File "", line 1, in ?
File "setup.py", line 35, in ?
import stdeb
ImportError: No module named stdeb
make: *** [build-python2.4] Error 1
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
Is this something to do with python versions?
So how do I limit the python versions for dpkg-buildpackage?
stdeb is 0.3
$ python -V
Python 2.5.2
Regards,
Gerry
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote: > Andrew Straw wrote: >> Gerry Reno wrote: >> >>> In my setup.py I have my own "install": >>> >>> from distutils.command.install import install >>> ... >>> class myinstall(install): >>> ... >>> >>> and when we call dpkg-buildpackage this local "install" seems to maybe >>> be causing the problem with the error: option >>> --single-version-externally-managed not recognized. >>> >>> How can we make this option be recognized? Do we need to inherit >>> something from setuptools? >>> >> I think there are 2 options: >> >> 1) upgrade to the nascent stdeb 0.4. It doesn't call setup.py with the >> --single-version-externally-managed argument. >> > I'm using Ubuntu 8.0.4 LTS Server and when I run apt-get it brings in > stdeb 0.3. I always use the distro packagers to install software so > how can I use apt-get to install stdeb 0.4? stdeb isn't in the Ubuntu (or Debian) repository. And I thought you said you used easy_install on it. Are you sure you can't just upgrade by hand? I can't see how else you got it. > >> I would suggest option 1. If you need me to make a release, I'm happy to >> do so -- but maybe that will be better after it has bdist_deb? :) >> > My only concern now with stdeb adding the bdist_deb command is that it > may not work like other 'bdist' commands. And having 'bdist_deb' work > similar to 'bdist_rpm' is important. It would have to use setup.cfg > for config and allow for pre/postinstall scripts to run. Well, to produce the final .deb file, stdeb produces a source package and then, in another process, calls the debian machinery may be called to produce the .deb file (I guess you're now quite familiar with that). I feel this approach benefits from using the standard Debian infrastructure. Specifically, python-support and debhelper 7 called by stdeb 0.4 do things like: install a single copy of the .py files and symlink them into the per-version directories, compile .pyc files per-version at install time, compile extension modules per-version at build time, and so on. Reproducing that would be hard, error prone, and a pointless duplication of effort. And .debs that don't do all that stuff that will be sub-standard and won't behave like those downloaded from the Debian/Ubuntu repos. Thus, I really think calling the real Debian machinery is the way to go. As I understand it (which is not well), bdist_rpm calls out to an "rpm" command from the original "python setup.py bdist_rpm" process, but at that point the binary is already made at this is just a packaging step. With stdeb, the initial output will be the source package which would be compiled to a binary by another process -- a subprocess of dpkg-buildpackage. You can control this binary generation by modifying debian/rules, which is a Makefile that is run to build the binary. So you can make sure that building the binary as done by the debian/rules file handles the options in setup.cfg. It should do that automatically, since what happens is a glorified "python setup.py install". As far as pre/postinstall scripts -- what do you need them to do? It would be possible to add support for stdeb to run these scripts at debian .deb install time. (stdeb already runs a preinstall script to ease the python-central -> python-support transition. See commit 9faaf049.) But if they're limited in scope and merely modify the files you want installed, they're probably already run as part of the .deb build process if you've hooked into the "install" command. I can't see how an infrastructure based only on extending the distutils install command could be used to distinguish between A) "pre/post-install" scripts that merely modify the files to be installed and could thus be run at package build time versus B) pre/post-install scripts that actually need to be run once the .deb package is being installed on the target system that might do something like start a web server. It seems there has to be a specification of the difference. -Andrew ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Andrew Straw wrote: Gerry Reno wrote: Andrew Straw wrote: Gerry Reno wrote: In my setup.py I have my own "install": from distutils.command.install import install ... class myinstall(install): ... and when we call dpkg-buildpackage this local "install" seems to maybe be causing the problem with the error: option --single-version-externally-managed not recognized. How can we make this option be recognized? Do we need to inherit something from setuptools? I think there are 2 options: 1) upgrade to the nascent stdeb 0.4. It doesn't call setup.py with the --single-version-externally-managed argument. I'm using Ubuntu 8.0.4 LTS Server and when I run apt-get it brings in stdeb 0.3. I always use the distro packagers to install software so how can I use apt-get to install stdeb 0.4? stdeb isn't in the Ubuntu (or Debian) repository. And I thought you said you used easy_install on it. Are you sure you can't just upgrade by hand? I can't see how else you got it. Yes, looking back you are right. I didn't find it with apt-get and had to use easy_install to get it (which I don't normally do). $ sudo easy_install --upgrade stdeb says stdeb 0.3 is best match and already installed. How do I get stdeb 0.4? I would suggest option 1. If you need me to make a release, I'm happy to do so -- but maybe that will be better after it has bdist_deb? :) My only concern now with stdeb adding the bdist_deb command is that it may not work like other 'bdist' commands. And having 'bdist_deb' work similar to 'bdist_rpm' is important. It would have to use setup.cfg for config and allow for pre/postinstall scripts to run. Well, to produce the final .deb file, stdeb produces a source package and then, in another process, calls the debian machinery may be called to produce the .deb file (I guess you're now quite familiar with that). I feel this approach benefits from using the standard Debian infrastructure. Specifically, python-support and debhelper 7 called by stdeb 0.4 do things like: install a single copy of the .py files and symlink them into the per-version directories, compile .pyc files per-version at install time, compile extension modules per-version at build time, and so on. Reproducing that would be hard, error prone, and a pointless duplication of effort. And .debs that don't do all that stuff that will be sub-standard and won't behave like those downloaded from the Debian/Ubuntu repos. Thus, I really think calling the real Debian machinery is the way to go. As I understand it (which is not well), bdist_rpm calls out to an "rpm" command from the original "python setup.py bdist_rpm" process, but at that point the binary is already made at this is just a packaging step. With stdeb, the initial output will be the source package which would be compiled to a binary by another process -- a subprocess of dpkg-buildpackage. You can control this binary generation by modifying debian/rules, which is a Makefile that is run to build the binary. So you can make sure that building the binary as done by the debian/rules file handles the options in setup.cfg. It should do that automatically, since what happens is a glorified "python setup.py install". As far as pre/postinstall scripts -- what do you need them to do? It would be possible to add support for stdeb to run these scripts at debian .deb install time. (stdeb already runs a preinstall script to ease the python-central -> python-support transition. See commit 9faaf049.) But if they're limited in scope and merely modify the files you want installed, they're probably already run as part of the .deb build process if you've hooked into the "install" command. I can't see how an infrastructure based only on extending the distutils install command could be used to distinguish between A) "pre/post-install" scripts that merely modify the files to be installed and could thus be run at package build time versus B) pre/post-install scripts that actually need to be run once the .deb package is being installed on the target system that might do something like start a web server. It seems there has to be a specification of the difference. For bdist_rpm the way that you get pre and postpackage install scripts to run during package install is by using the following in the setup.cfg: [bdist_rpm] install_script = rpm_install_sh.txt then rpm_install_sh.txt gets inserted into the rpm .spec file at the %install marker. Now you can also add other sections into rpm_install_sh.txt like %pre and %post which are sections of shell scripts that run prepackage and postpackage install. As far as 'python setup.py install' build type pre/postinstall, you can subclass install class and just run some scripts either side of parent "install" class. Regards, Gerry ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote: > How do I get stdeb 0.4? The easiest way: git clone git://github.com/astraw/stdeb.git cd stdeb sudo python setup.py install If you want a tarball, please look at my email 09/19/2009 09:36 PM -0700. > For bdist_rpm the way that you get pre and postpackage install scripts > to run during package install is by using > the following in the setup.cfg: > [bdist_rpm] > install_script = rpm_install_sh.txt > > then rpm_install_sh.txt gets inserted into the rpm .spec file at the > %install marker. Now you can also add other sections into > rpm_install_sh.txt like %pre and %post which are sections of shell > scripts that run prepackage and postpackage install. As far as > 'python setup.py install' build type pre/postinstall, you can subclass > install class and just run some scripts either side of parent > "install" class. I think it would be straightforward to integrate something similar into stdeb. I'm not too much in favor of piggybacking distutils' infrastructure to parse the setup.cfg file, though. Perhaps we could parse setup.cfg on our own (i.e. replace looking for stdeb.cfg with looking for setup.cfg and changing the section name appropriately). In the near term the easiest thing is to stick with the stdeb.cfg file for now and and a new field for each of pre/post install and pre/post remove. -Andrew ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Andrew Straw wrote: Gerry Reno wrote: How do I get stdeb 0.4? The easiest way: git clone git://github.com/astraw/stdeb.git cd stdeb sudo python setup.py install If you want a tarball, please look at my email 09/19/2009 09:36 PM -0700. Ok, I'll install 0.4 using one of these methods. What should I do about the easy_installed stdeb 0.3? Should I try to "remove" 0.3 (I use that term loosely wrt easy_install) using -m? For bdist_rpm the way that you get pre and postpackage install scripts to run during package install is by using the following in the setup.cfg: [bdist_rpm] install_script = rpm_install_sh.txt then rpm_install_sh.txt gets inserted into the rpm .spec file at the %install marker. Now you can also add other sections into rpm_install_sh.txt like %pre and %post which are sections of shell scripts that run prepackage and postpackage install. As far as 'python setup.py install' build type pre/postinstall, you can subclass install class and just run some scripts either side of parent "install" class. I think it would be straightforward to integrate something similar into stdeb. I'm not too much in favor of piggybacking distutils' infrastructure to parse the setup.cfg file, though. Perhaps we could parse setup.cfg on our own (i.e. replace looking for stdeb.cfg with looking for setup.cfg and changing the section name appropriately). In the near term the easiest thing is to stick with the stdeb.cfg file for now and and a new field for each of pre/post install and pre/post remove. My preference would be to see something like this maybe in setup.cfg: [bdist_deb] pre_install_script = deb_pre_install.sh post_install_script = deb_post_install.sh pre_uninstall_script = deb_pre_uninstall.sh post_uninstall_script = deb_post_uninstall.sh This is what I was intending to do using the 'bdist_deb' command extension to distutils. And that way our users have only one config file they need to be concerned about. Regards, Gerry P.S.: Things that totally frustrate me wrt python: distutils/setuptools and apt-get(or rpm)/easy_install battles/incompatibilities/duplications. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote: Andrew Straw wrote: Gerry Reno wrote: How do I get stdeb 0.4? The easiest way: git clone git://github.com/astraw/stdeb.git cd stdeb sudo python setup.py install If you want a tarball, please look at my email 09/19/2009 09:36 PM -0700. Ok, I'll install 0.4 using one of these methods. What should I do about the easy_installed stdeb 0.3? Should I try to "remove" 0.3 (I use that term loosely wrt easy_install) using -m? Ok, I d/l the tarball which installed 0.3-dh7. But this created new problems: Unmet dependencies: debhelper >= 7 python-support >= 0.8.7 Installed: debhelper6.0.4 python-support0.7.5 It's going to be tough to get stdeb running on Ubuntu 8.0.4 LTS. Regards, Gerry So I ran apt-get upgrade ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote: > > It's going to be tough to get stdeb running on Ubuntu 8.0.4 LTS. Well, I'd qualify that with stdeb version 0.4 may be more tough to get running. It is the bleeding edge, after all. :) 0.3 works as well as it ever did, but new features are going into 0.4. But now that you mention it, I have backported debhelper and python-support to Hardy. See http://debs.astraw.com/hardy you can download the binaries or source packages from there. (You can also add my repo to your /etc/apt/sources.list) -Andrew ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Andrew Straw wrote: Gerry Reno wrote: It's going to be tough to get stdeb running on Ubuntu 8.0.4 LTS. Well, I'd qualify that with stdeb version 0.4 may be more tough to get running. It is the bleeding edge, after all. :) 0.3 works as well as it ever did, but new features are going into 0.4. But now that you mention it, I have backported debhelper and python-support to Hardy. See http://debs.astraw.com/hardy you can download the binaries or source packages from there. (You can also add my repo to your /etc/apt/sources.list) Wow, there's quite a few packages there. Is debhelper and python-support all that are needed or do I need any others because of dependencies? Regards, Gerry ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote: > Andrew Straw wrote: >> Gerry Reno wrote: >> >>> It's going to be tough to get stdeb running on Ubuntu 8.0.4 LTS. >>> >> Well, I'd qualify that with stdeb version 0.4 may be more tough to get >> running. It is the bleeding edge, after all. :) 0.3 works as well as it >> ever did, but new features are going into 0.4. >> >> But now that you mention it, I have backported debhelper and >> python-support to Hardy. See http://debs.astraw.com/hardy you can >> download the binaries or source packages from there. (You can also add >> my repo to your /etc/apt/sources.list) >> > Wow, there's quite a few packages there. Is debhelper and > python-support all that are needed or do I need any others because of > dependencies? I can't remember -- you'll have to attempt installation to find out. I think there are some but not too many dependencies that need to be upgraded (I guess on the order of 5 packages or so). -Andrew ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Andrew Straw wrote: Gerry Reno wrote: Andrew Straw wrote: Gerry Reno wrote: It's going to be tough to get stdeb running on Ubuntu 8.0.4 LTS. Well, I'd qualify that with stdeb version 0.4 may be more tough to get running. It is the bleeding edge, after all. :) 0.3 works as well as it ever did, but new features are going into 0.4. But now that you mention it, I have backported debhelper and python-support to Hardy. See http://debs.astraw.com/hardy you can download the binaries or source packages from there. (You can also add my repo to your /etc/apt/sources.list) Wow, there's quite a few packages there. Is debhelper and python-support all that are needed or do I need any others because of dependencies? I can't remember -- you'll have to attempt installation to find out. I think there are some but not too many dependencies that need to be upgraded (I guess on the order of 5 packages or so). Ok, here is the simplest way that I got stdeb working on Hardy: $ easy_install stdeb # installs 0.3 copied stdeb egg to workarea and edited util.py and removed all "--single-version-externally-managed" options repackaged egg copied egg back to site-packages Now dpkg-buildpackage is happy and no more complaints about unrecognized option or missing dependencies. So my question is this: can you make a special version of the current stdeb 0.3 without the --single-version-externally-managed options and put it into your hardy repo? This would be much easier and less worrisome to hardy users than trying to get them to upgrade a lot of different packages. Regards, Gerry ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote: > Ok, here is the simplest way that I got stdeb working on Hardy: > $ easy_install stdeb # installs 0.3 > copied stdeb egg to workarea and edited util.py and removed all > "--single-version-externally-managed" options > repackaged egg > copied egg back to site-packages OK, but now your packages built with stdeb going to be (even more) different from standard Debian/Ubuntu Python packages -- they're going to install their files as an .egg (directory or zip file). For example, do "dpkg --contents python-my-package_1.0-1.deb" and compare that to standard python packages. > Now dpkg-buildpackage is happy and no more complaints about > unrecognized option or missing dependencies. > > So my question is this: can you make a special version of the current > stdeb 0.3 without the --single-version-externally-managed options and > put it into your hardy repo? No -- I already have debhelper 7 and friends in my hardy repo. If I put stdeb in at all, it would be 0.4. I won't go back to stdeb 0.3, especially a broken version of 0.3. > This would be much easier and less worrisome to hardy users than > trying to get them to upgrade a lot of different packages. I don't have enough time to work on stdeb as-is, and my development efforts going forward will continue to use debhelper 7 and python-support, not to work on backporting stuff. I can say my packages are installed on lots of hardy machines (over 20 at last count) and haven't caused troubles that I know of. I'm careful to put the source online, too, in case you want to look at my changes or compile yourself. If you want to work off the "old-stable" branch in my github account, that's where the 0.3 branch still lives. Anyhow, if you come up with a bdist_deb type patch, I'd be interested to take a look and could probably merge it from the old-stable branch onto the master branch. -Andrew ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote: > Andrew Straw wrote: >> Gerry Reno wrote: >> >>> Ok, here is the simplest way that I got stdeb working on Hardy: >>> $ easy_install stdeb # installs 0.3 >>> copied stdeb egg to workarea and edited util.py and removed all >>> "--single-version-externally-managed" options >>> repackaged egg >>> copied egg back to site-packages >>> >> OK, but now your packages built with stdeb going to be (even more) >> different from standard Debian/Ubuntu Python packages -- they're going >> to install their files as an .egg (directory or zip file). For example, >> do "dpkg --contents python-my-package_1.0-1.deb" and compare that to >> standard python packages. >> > Ok, I just built a .deb using modified stdeb 0.3 on hardy and looked > at the contents and it's like this: > ./usr/share/pyshared/myapp/dir1/...(list of files) > ./usr/share/pyshared/myapp/dir2/... > ./usr/share/pyshared/myapp/dir3/... > > I don't see anything about egg. And it looks very similar to other > .deb in /var/cache that I checked. That's good. And surprising to me... > How much difference would I see if it was egg? Hmm, good question. Now that you find this, I'm really not sure. Scratches head and wonders if he's been basing his ideas off old versions of software, -Andrew ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Andrew Straw wrote: Gerry Reno wrote: Ok, here is the simplest way that I got stdeb working on Hardy: $ easy_install stdeb # installs 0.3 copied stdeb egg to workarea and edited util.py and removed all "--single-version-externally-managed" options repackaged egg copied egg back to site-packages OK, but now your packages built with stdeb going to be (even more) different from standard Debian/Ubuntu Python packages -- they're going to install their files as an .egg (directory or zip file). For example, do "dpkg --contents python-my-package_1.0-1.deb" and compare that to standard python packages. Ok, I just built a .deb using modified stdeb 0.3 on hardy and looked at the contents and it's like this: ./usr/share/pyshared/myapp/dir1/...(list of files) ./usr/share/pyshared/myapp/dir2/... ./usr/share/pyshared/myapp/dir3/... I don't see anything about egg. And it looks very similar to other .deb in /var/cache that I checked. How much difference would I see if it was egg? Regards, Gerry ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Andrew, Ok, .deb is building fine using modified stdeb 0.3 on hardy. I've installed the .deb and it works. I can see that stdeb is using debhelper which I really don't know much about. So it looks like debhelper or dh_make is generating the control files. What I need is someway that in myapp maybe under a debian/ directory, I can create postinst and prerm files and then stdeb would look for those in the orig tarball and use them if found. Is this possible? Regards, Gerry ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote: > Andrew, Ok, .deb is building fine using modified stdeb 0.3 on hardy. > I've installed the .deb and it works. > > I can see that stdeb is using debhelper which I really don't know much > about. So it looks like debhelper or dh_make is generating the > control files. What I need is someway that in myapp maybe under a > debian/ directory, I can create postinst and prerm files and then > stdeb would look for those in the orig tarball and use them if found. > Is this possible? The debian packaging machinery invoked by dpkg-buildpackage will pick up any scripts named my-package-name.preinst, my-package-name.postinst, my-package-name.prerm, my-package-name.postrm that happen to be in the debian/ directory. See http://sdn.vlsm.org/share/Debian-Doc/manuals/maint-guide/ch-dother.en.html for more info. So you have to modify stdeb to drop the appropriate files in there if they're given as a config argument to stdeb. The stdeb master branch already creates such a file for housekeeping reasons (see commit http://github.com/astraw/stdeb/commit/9faaf049a1a7fbd8f5e1fb658248013f208f398c where I added this). -Andrew ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Andrew Straw wrote: Gerry Reno wrote: Andrew, Ok, .deb is building fine using modified stdeb 0.3 on hardy. I've installed the .deb and it works. I can see that stdeb is using debhelper which I really don't know much about. So it looks like debhelper or dh_make is generating the control files. What I need is someway that in myapp maybe under a debian/ directory, I can create postinst and prerm files and then stdeb would look for those in the orig tarball and use them if found. Is this possible? The debian packaging machinery invoked by dpkg-buildpackage will pick up any scripts named my-package-name.preinst, my-package-name.postinst, my-package-name.prerm, my-package-name.postrm that happen to be in the debian/ directory. See http://sdn.vlsm.org/share/Debian-Doc/manuals/maint-guide/ch-dother.en.html for more info. So you have to modify stdeb to drop the appropriate files in there if they're given as a config argument to stdeb. The stdeb master branch already creates such a file for housekeeping reasons (see commit http://github.com/astraw/stdeb/commit/9faaf049a1a7fbd8f5e1fb658248013f208f398c where I added this). I really didn't have to use any stdeb config args or anything. I just created a dir myapp/debian and put a python-myapp.postinst script file in there, ran my bdist_deb command and then installed the .deb and the python-myapp.postinst script ran perfectly. So do I need to be concerned with config args to stdeb? I do see some python-myapp.postinst.debhelper etc. scripts in there but I don't know if those ran. Regards, Gerry ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote: I really didn't have to use any stdeb config args or anything. I just created a dir myapp/debian and put a python-myapp.postinst script file in there, ran my bdist_deb command and then installed the .deb and the python-myapp.postinst script ran perfectly. So do I need to be concerned with config args to stdeb? I do see some python-myapp.postinst.debhelper etc. scripts in there but I don't know if those ran. So now everything is working on hardy except for the fact that stdeb 0.3 has to be modified to remove the --single-version-externally-managed option. So can you just create a 0.3a version with this small change and that could go out to the repositories and be available by default to everyone. There does not seem to be any impact that I can see in making this change and since so many people create their own install classes this would actually prevent conflicts. Regards, Gerry ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote: > Gerry Reno wrote: >> >> I really didn't have to use any stdeb config args or anything. I just >> created a dir myapp/debian and put a python-myapp.postinst script file >> in there, ran my bdist_deb command and then installed the .deb and the >> python-myapp.postinst script ran perfectly. So do I need to be >> concerned with config args to stdeb? I do see some >> python-myapp.postinst.debhelper etc. scripts in there but I don't know >> if those ran. >> > > So now everything is working on hardy except for the fact that stdeb 0.3 > has to be modified to remove the --single-version-externally-managed > option. So can you just create a 0.3a version with this small change and > that could go out to the repositories and be available by default to > everyone. There does not seem to be any impact that I can see in making > this change and since so many people create their own install classes > this would actually prevent conflicts. I figured out what the reason for --single-version-externally-managed is -- it is required for namespace packages to function properly. Thus, I can't remove it, as doing so would be a regression. However, if you create a patch I can apply against the old-stable branch that makes this optional, (e.g. set in a similar way as the --ignore-install-requires option), I can add that and make release 0.3.1. Note also that I'm very close to releasing 0.4, as the 0.3 line has major problems with Jaunty and later. Are you planning to submit a patch for the bdist_deb command? I could include that, too. -Andrew ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Andrew Straw wrote:
Gerry Reno wrote:
So now everything is working on hardy except for the fact that stdeb 0.3
has to be modified to remove the --single-version-externally-managed
option. So can you just create a 0.3a version with this small change and
that could go out to the repositories and be available by default to
everyone. There does not seem to be any impact that I can see in making
this change and since so many people create their own install classes
this would actually prevent conflicts.
I figured out what the reason for --single-version-externally-managed is
-- it is required for namespace packages to function properly. Thus, I
can't remove it, as doing so would be a regression.
However, if you create a patch I can apply against the old-stable branch
that makes this optional, (e.g. set in a similar way as the
--ignore-install-requires option), I can add that and make release
0.3.1.
Ok, I'll look at getting you a patch that removes the option.
Note also that I'm very close to releasing 0.4, as the 0.3 line
has major problems with Jaunty and later.
Are you planning to submit a patch for the bdist_deb command? I could
include that, too.
Yes, I have something ready but I think the 'bdist_deb' command belongs
as a distutils patch. I created the command by subclassing the
distutils Command class. Maybe Tarek could comment on what might be
best here.
Here is my working 'bdist_deb' code verbatim from inside my setup.py:
(it could be more pythonic of course with less os.system commands but
it's working real well this way at least)
=
# Copyright 2009 Gerry Reno.
# stdeb note:
# stdeb 0.3 needs its util.py modified to remove the install
# option "--single-version-externally-managed" otherwise
# if you have subclassed the distutils install class to
# create your own "install" class (rather common) you will
# get an "unrecognized option" error when using 'bdist_deb'.
# I had to make this change to stdeb in order to get stdeb to work
# on Ubuntu Hardy with a setup.py that defined its own install.
from distutils.core import Command
if sys.hexversion >= 0x020500F0:
import stdeb
elif sys.argv[1] == 'bdist_deb':
print sys.argv[1], "requires python >= 2.5"
raise SystemExit(1)
class bdist_deb(Command):
# creates .deb pkg from a .dsc file that is generated using stdeb module
# requires stdeb, dpkg-dev, build-essential, python-all-dev,
debhelper, python-support, fakeroot
#
# to add 'postinst' and friends just create a debian/ control
directory in the home directory of your
# application and add a file 'python-myapp.postinst' and it will be
run post package installation.
description = 'Create debian-style source (.dsc using stdeb module)
and binary (.deb) packages'
user_options = [('install-dir=', 'd', "directory to install the
files to"),
]
def initialize_options (self):
self.install_dir = None
self.outfiles = []
def finalize_options (self):
pass
def run(self):
import setuptools
import commands
# run a sub_command (gen .dsc source pkg using stdeb)
self.run_command('sdist_dsc')
# save current directory
setup_dir = os.getcwd()
# define system command to execute (find source pkg work tree)
syscmd = ['find', 'deb_dist', '-mindepth', '1', '-maxdepth',
'1', '-type', 'd',]
# execute system command and read output (execute and read
output of find cmd)
dsc_tree = strip(subprocess.Popen(syscmd,
stdout=subprocess.PIPE).communicate()[0]) # strip needed to remove CR
# use system command output (change directory to work tree)
os.chdir(dsc_tree)
# define system command to execute (gen .deb binary pkg)
syscmd = 'dpkg-buildpackage -rfakeroot -uc -us'
# execute system command
if os.system(syscmd) == 0:
print '.deb successfully created in deb_dist/'
else:
print 'problem creating .deb'
# (change directory back to setup dir)
os.chdir(setup_dir)
setup(name = name,
...
# add new bdist_deb command here
cmdclass = {
...
'bdist_deb' : bdist_deb,
...
},
...
)
=
Regards,
Gerry
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote:
Andrew Straw wrote:
Gerry Reno wrote:
So now everything is working on hardy except for the fact that stdeb
0.3
has to be modified to remove the --single-version-externally-managed
option. So can you just create a 0.3a version with this small change
and
that could go out to the repositories and be available by default to
everyone. There does not seem to be any impact that I can see in making
this change and since so many people create their own install classes
this would actually prevent conflicts.
I figured out what the reason for --single-version-externally-managed is
-- it is required for namespace packages to function properly. Thus, I
can't remove it, as doing so would be a regression.
However, if you create a patch I can apply against the old-stable branch
that makes this optional, (e.g. set in a similar way as the
--ignore-install-requires option), I can add that and make release
0.3.1.
Ok, I'll look at getting you a patch that removes the option.
Patch to utils.py in old-stable branch attached.
Note also that I'm very close to releasing 0.4, as the 0.3 line
has major problems with Jaunty and later.
Are you planning to submit a patch for the bdist_deb command? I could
include that, too.
Yes, I have something ready but I think the 'bdist_deb' command
belongs as a distutils patch. I created the command by subclassing the
distutils Command class. Maybe Tarek could comment on what might be
best here.
Here is my working 'bdist_deb' code verbatim from inside my setup.py:
(it could be more pythonic of course with less os.system commands but
it's working real well this way at least)
=
# Copyright 2009 Gerry Reno.
# stdeb note:
# stdeb 0.3 needs its util.py modified to remove the install
# option "--single-version-externally-managed" otherwise
# if you have subclassed the distutils install class to
# create your own "install" class (rather common) you will
# get an "unrecognized option" error when using 'bdist_deb'.
# I had to make this change to stdeb in order to get stdeb to work
# on Ubuntu Hardy with a setup.py that defined its own install.
from distutils.core import Command
if sys.hexversion >= 0x020500F0:
import stdeb
elif sys.argv[1] == 'bdist_deb':
print sys.argv[1], "requires python >= 2.5"
raise SystemExit(1)
class bdist_deb(Command):
# creates .deb pkg from a .dsc file that is generated using stdeb module
# requires stdeb, dpkg-dev, build-essential, python-all-dev,
debhelper, python-support, fakeroot
#
# to add 'postinst' and friends just create a debian/ control
directory in the home directory of your
# application and add a file 'python-myapp.postinst' and it will be
run post package installation.
description = 'Create debian-style source (.dsc using stdeb module)
and binary (.deb) packages'
user_options = [ ('install-dir=', 'd', "directory to install the files
to"),
]
def initialize_options (self):
self.install_dir = None
self.outfiles = []
def finalize_options (self):
pass
def run(self):
import setuptools
import commands
# run a sub_command (gen .dsc source pkg using stdeb)
self.run_command('sdist_dsc')
# save current directory
setup_dir = os.getcwd()
# define system command to execute (find source pkg work tree)
syscmd = ['find', 'deb_dist', '-mindepth', '1', '-maxdepth', '1',
'-type', 'd',]
# execute system command and read output (execute and read output of
find cmd)
dsc_tree = strip(subprocess.Popen(syscmd,
stdout=subprocess.PIPE).communicate()[0]) # strip needed to remove CR
# use system command output (change directory to work tree)
os.chdir(dsc_tree)
# define system command to execute (gen .deb binary pkg)
syscmd = 'dpkg-buildpackage -rfakeroot -uc -us'
# execute system command
if os.system(syscmd) == 0:
print '.deb successfully created in deb_dist/'
else:
print 'problem creating .deb'
# (change directory back to setup dir)
os.chdir(setup_dir)
setup(name = name,
...
# add new bdist_deb command here
cmdclass = {
...
'bdist_deb' : bdist_deb,
...
},
...
)
=
Regards,
Gerry
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
953c953
< --no-compile --single-version-externally-managed \\
---
> --no-compile \\
959c959
< --no-compile --single-version-externally-managed --install-layout=deb \\
---
> --no-compile --install-layout=deb \\
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote:
> Gerry Reno wrote:
>> Andrew Straw wrote:
>>> Gerry Reno wrote:
So now everything is working on hardy except for the fact that
stdeb 0.3
has to be modified to remove the --single-version-externally-managed
option. So can you just create a 0.3a version with this small
change and
that could go out to the repositories and be available by default to
everyone. There does not seem to be any impact that I can see in
making
this change and since so many people create their own install classes
this would actually prevent conflicts.
>>>
>>> I figured out what the reason for
>>> --single-version-externally-managed is
>>> -- it is required for namespace packages to function properly. Thus, I
>>> can't remove it, as doing so would be a regression.
>>>
>>> However, if you create a patch I can apply against the old-stable
>>> branch
>>> that makes this optional, (e.g. set in a similar way as the
>>> --ignore-install-requires option), I can add that and make release
>>> 0.3.1.
>> Ok, I'll look at getting you a patch that removes the option.
>
>
> Patch to utils.py in old-stable branch attached.
I saw your patch, but that wasn't what I meant. Disabling
--single-version-externally-managed has to be optional, and the argument
must continue to be used by default. Simply removing the call will
create a regression for namespace packages. Thus, the
--single-version-externally-managed should only be removed when someone
explicitly asks for it to be removed (because they presumably know what
they're doing or are at least aware it may have negative consequences).
Hence my suggestion to look at how the --ignore-install-requires works
as an example of how to pass an option via the distuils infrastructure.
>>> Note also that I'm very close to releasing 0.4, as the 0.3 line
>>> has major problems with Jaunty and later.
>>>
>>> Are you planning to submit a patch for the bdist_deb command? I could
>>> include that, too.
>> Yes, I have something ready but I think the 'bdist_deb' command
>> belongs as a distutils patch. I created the command by subclassing
>> the distutils Command class. Maybe Tarek could comment on what might
>> be best here.
>> Here is my working 'bdist_deb' code verbatim from inside my setup.py:
OK, based on your code I added a "bdist_deb" distutils command to stdeb.
I've checked this into the old-stable branch and I'd appreciate it if
you can check whether this works for you and send me any comments.
Invoke it like this:
python -c "import stdeb; excecfile('setup.py')" bdist_deb
The implementation is in the old-stable branch
http://github.com/astraw/stdeb/commits/old-stable I will merge this into
the master branch soon.
-Andrew
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Andrew Straw wrote:
I saw your patch, but that wasn't what I meant. Disabling
--single-version-externally-managed has to be optional, and the argument
must continue to be used by default. Simply removing the call will
create a regression for namespace packages. Thus, the
--single-version-externally-managed should only be removed when someone
explicitly asks for it to be removed (because they presumably know what
they're doing or are at least aware it may have negative consequences).
Hence my suggestion to look at how the --ignore-install-requires works
as an example of how to pass an option via the distuils infrastructure.
I'll look at --ignore-install-requires and send another patch.
OK, based on your code I added a "bdist_deb" distutils command to stdeb.
I've checked this into the old-stable branch and I'd appreciate it if
you can check whether this works for you and send me any comments.
Invoke it like this:
python -c "import stdeb; excecfile('setup.py')" bdist_deb
See this was my point of why my 'bdist_deb' belonged as a distutils
patch and not in stdeb.
The inherited capabilities, behaviors and invocation style needs to
follow all the other 'bdist' command types.
And that means being able to invoke it the same as say 'bdist_rpm' like:
python setup.py bdist_deb
or
python setup.py bdist_deb -- ...
If we start allowing 'bdist' derivative commands to diverge in their
inherited capabilities, invocation style, and expected behaviors then
chaos will ensue.
Regards,
Gerry
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote:
> Andrew Straw wrote:
>>
>> I saw your patch, but that wasn't what I meant. Disabling
>> --single-version-externally-managed has to be optional, and the argument
>> must continue to be used by default. Simply removing the call will
>> create a regression for namespace packages. Thus, the
>> --single-version-externally-managed should only be removed when someone
>> explicitly asks for it to be removed (because they presumably know what
>> they're doing or are at least aware it may have negative consequences).
>> Hence my suggestion to look at how the --ignore-install-requires works
>> as an example of how to pass an option via the distuils infrastructure.
>>
>>
> I'll look at --ignore-install-requires and send another patch.
OK, great.
>> OK, based on your code I added a "bdist_deb" distutils command to stdeb.
>> I've checked this into the old-stable branch and I'd appreciate it if
>> you can check whether this works for you and send me any comments.
>> Invoke it like this:
>>
>> python -c "import stdeb; excecfile('setup.py')" bdist_deb
>>
> See this was my point of why my 'bdist_deb' belonged as a distutils
> patch and not in stdeb.
> The inherited capabilities, behaviors and invocation style needs to
> follow all the other 'bdist' command types.
> And that means being able to invoke it the same as say 'bdist_rpm' like:
>
> python setup.py bdist_deb
> or
> python setup.py bdist_deb -- ...
>
> If we start allowing 'bdist' derivative commands to diverge in their
> inherited capabilities, invocation style, and expected behaviors then
> chaos will ensue.
This does have the same invocation style -- if you change your setup.py
to import stdeb. Otherwise, it's still the same invocation style -- you
just have to import stdeb outside the setup.py file.
Also, this version of bdist_deb is never going to make it into the
standard library as it depends on stdeb.
So feel free to make a counter proposal, but I'm inclined to think this
is useful to people as-is and has the benefit of working today.
-Andrew
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Andrew Straw wrote:
Gerry Reno wrote:
Andrew Straw wrote:
I saw your patch, but that wasn't what I meant. Disabling
--single-version-externally-managed has to be optional, and the argument
must continue to be used by default. Simply removing the call will
create a regression for namespace packages. Thus, the
--single-version-externally-managed should only be removed when someone
explicitly asks for it to be removed (because they presumably know what
they're doing or are at least aware it may have negative consequences).
Hence my suggestion to look at how the --ignore-install-requires works
as an example of how to pass an option via the distuils infrastructure.
I'll look at --ignore-install-requires and send another patch.
OK, great.
OK, based on your code I added a "bdist_deb" distutils command to stdeb.
I've checked this into the old-stable branch and I'd appreciate it if
you can check whether this works for you and send me any comments.
Invoke it like this:
python -c "import stdeb; excecfile('setup.py')" bdist_deb
See this was my point of why my 'bdist_deb' belonged as a distutils
patch and not in stdeb.
The inherited capabilities, behaviors and invocation style needs to
follow all the other 'bdist' command types.
And that means being able to invoke it the same as say 'bdist_rpm' like:
python setup.py bdist_deb
or
python setup.py bdist_deb -- ...
If we start allowing 'bdist' derivative commands to diverge in their
inherited capabilities, invocation style, and expected behaviors then
chaos will ensue.
This does have the same invocation style -- if you change your setup.py
to import stdeb. Otherwise, it's still the same invocation style -- you
just have to import stdeb outside the setup.py file.
Also, this version of bdist_deb is never going to make it into the
standard library as it depends on stdeb.
So feel free to make a counter proposal, but I'm inclined to think this
is useful to people as-is and has the benefit of working today.
My view is this. The 'bdist' family of commands should be reserved for
pure Distutils implementations not dependent upon setuptools or stdeb.
Putting a command to create the .deb based on my code into stdeb is fine
but that command should not be a 'bdist_xxx' command. It should be
somthing like bstdeb_deb so that a true 'bdist_deb' can still be
developed for Distutils and not be in conflict with some other
'bdist_deb' out there.
At some point, the 'bdist' family of commands should evolve into
OS-specific varieties. And this means that for example, redhat, fedora,
mandriva, or any other rpm-package distro would have their own
'bdist_DISTRO' command that would inherit from 'bdist_rpm' and then
institute their own rules/policies onto a generic 'bdist_rpm'. And the
same would hold true for example a 'bdist_ubuntu' command that would
inherit from a 'bdist_deb' command or in general for any 'bdist_DISTRO'
command that would inherit from a 'bdist_PACKAGETOOL' command.
Maybe we can get some overall guidance here from Tarek who has been
coordinating a lot of these types of things.
Regards,
Gerry
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
OK, based on your code I added a "bdist_deb" distutils command to
stdeb.
I've checked this into the old-stable branch and I'd appreciate it if
you can check whether this works for you and send me any comments.
Invoke it like this:
python -c "import stdeb; excecfile('setup.py')" bdist_deb
>>> See this was my point of why my 'bdist_deb' belonged as a distutils
>>> patch and not in stdeb.
>>> The inherited capabilities, behaviors and invocation style needs to
>>> follow all the other 'bdist' command types.
>>> And that means being able to invoke it the same as say 'bdist_rpm'
>>> like:
>>>
>>> python setup.py bdist_deb
>>> or
>>> python setup.py bdist_deb -- ...
>>>
>>> If we start allowing 'bdist' derivative commands to diverge in their
>>> inherited capabilities, invocation style, and expected behaviors then
>>> chaos will ensue.
>>>
>> This does have the same invocation style -- if you change your setup.py
>> to import stdeb. Otherwise, it's still the same invocation style -- you
>> just have to import stdeb outside the setup.py file.
>>
>> Also, this version of bdist_deb is never going to make it into the
>> standard library as it depends on stdeb.
>>
>> So feel free to make a counter proposal, but I'm inclined to think this
>> is useful to people as-is and has the benefit of working today.
>>
>>
> My view is this. The 'bdist' family of commands should be reserved
> for pure Distutils implementations not dependent upon setuptools or
> stdeb. Putting a command to create the .deb based on my code into
> stdeb is fine but that command should not be a 'bdist_xxx' command.
> It should be somthing like bstdeb_deb so that a true 'bdist_deb' can
> still be developed for Distutils and not be in conflict with some
> other 'bdist_deb' out there.
Well, it wouldn't be setting a precedent that importing a module would
extend the functionality of the stdlib's distutils commands -- the
setuptools and distribute projects already do this. For example, the
"sdist" command in setuptools has many differences with that of "sdist"
in plain distutils. The point is that a user can choose not to import
setuptools and thus not get the different behavior.
The case here is that if the stdlib ever grows bdist_deb, that's fine,
but I don't see why that should prevent stdeb from implementing a
bdist_deb command of its own. In this case, I think the issue is even
less relevant, since there is no stdlib "bdist_deb" command. Users would
naturally expect "bdist_deb" to do exactly what stdeb is implementing.
As long as I'm going ahead an implementing the functionality (which I'm
ambivalent about in and of itself for previously stated reasons), I
think it should be named the most obvious name.
> At some point, the 'bdist' family of commands should evolve into
> OS-specific varieties. And this means that for example, redhat,
> fedora, mandriva, or any other rpm-package distro would have their own
> 'bdist_DISTRO' command that would inherit from 'bdist_rpm' and then
> institute their own rules/policies onto a generic 'bdist_rpm'. And
> the same would hold true for example a 'bdist_ubuntu' command that
> would inherit from a 'bdist_deb' command or in general for any
> 'bdist_DISTRO' command that would inherit from a 'bdist_PACKAGETOOL'
> command.
I don't see what's so specific about ubuntu versus debian right now that
there's any reason for a different set of commands for the two.
Therefore, I think this is a red herring w.r.t. the present discussion.
> Maybe we can get some overall guidance here from Tarek who has been
> coordinating a lot of these types of things.
Sure. CCed.
-Andrew
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Andrew Straw wrote:
OK, based on your code I added a "bdist_deb" distutils command to
stdeb.
I've checked this into the old-stable branch and I'd appreciate it if
you can check whether this works for you and send me any comments.
Invoke it like this:
python -c "import stdeb; excecfile('setup.py')" bdist_deb
See this was my point of why my 'bdist_deb' belonged as a distutils
patch and not in stdeb.
The inherited capabilities, behaviors and invocation style needs to
follow all the other 'bdist' command types.
And that means being able to invoke it the same as say 'bdist_rpm'
like:
python setup.py bdist_deb
or
python setup.py bdist_deb -- ...
If we start allowing 'bdist' derivative commands to diverge in their
inherited capabilities, invocation style, and expected behaviors then
chaos will ensue.
This does have the same invocation style -- if you change your setup.py
to import stdeb. Otherwise, it's still the same invocation style -- you
just have to import stdeb outside the setup.py file.
Also, this version of bdist_deb is never going to make it into the
standard library as it depends on stdeb.
So feel free to make a counter proposal, but I'm inclined to think this
is useful to people as-is and has the benefit of working today.
My view is this. The 'bdist' family of commands should be reserved
for pure Distutils implementations not dependent upon setuptools or
stdeb. Putting a command to create the .deb based on my code into
stdeb is fine but that command should not be a 'bdist_xxx' command.
It should be somthing like bstdeb_deb so that a true 'bdist_deb' can
still be developed for Distutils and not be in conflict with some
other 'bdist_deb' out there.
Well, it wouldn't be setting a precedent that importing a module would
extend the functionality of the stdlib's distutils commands -- the
setuptools and distribute projects already do this. For example, the
"sdist" command in setuptools has many differences with that of "sdist"
in plain distutils. The point is that a user can choose not to import
setuptools and thus not get the different behavior.
The case here is that if the stdlib ever grows bdist_deb, that's fine,
but I don't see why that should prevent stdeb from implementing a
bdist_deb command of its own. In this case, I think the issue is even
less relevant, since there is no stdlib "bdist_deb" command. Users would
naturally expect "bdist_deb" to do exactly what stdeb is implementing.
As long as I'm going ahead an implementing the functionality (which I'm
ambivalent about in and of itself for previously stated reasons), I
think it should be named the most obvious name.
My only concern is that namespaces are important and if we end up with
two solution paths that each use the same namespace then this becomes
very confusing for users. Yes, I understand that if you don't import
stdeb in your setup.py then you can use a 'bdist_deb' from Distutils.
At some point, the 'bdist' family of commands should evolve into
OS-specific varieties. And this means that for example, redhat,
fedora, mandriva, or any other rpm-package distro would have their own
'bdist_DISTRO' command that would inherit from 'bdist_rpm' and then
institute their own rules/policies onto a generic 'bdist_rpm'. And
the same would hold true for example a 'bdist_ubuntu' command that
would inherit from a 'bdist_deb' command or in general for any
'bdist_DISTRO' command that would inherit from a 'bdist_PACKAGETOOL'
command.
I don't see what's so specific about ubuntu versus debian right now that
there's any reason for a different set of commands for the two.
Therefore, I think this is a red herring w.r.t. the present discussion.
For ubuntu, at the moment at least, that's true. But distros like
redhat are creating their own rules/policies around rpm naming
conventions, build options, etc. and of course they should be able to do
this and I expect other distros will do the same, and these will diverge
more over time even though they will all use the same packaging tool
underneath.
Maybe we can get some overall guidance here from Tarek who has been
coordinating a lot of these types of things.
I think this is a good topic for someone with a long view about where
things are headed here to weigh in on this.
I'm fine with whatever fits in with the longer term goals.
Regards,
Gerry
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Andrew,
Here's another patch attempt. Is this what you had in mind?
Regards,
Gerry
51a52,53
> ('ignore-single-version-externally-managed', 's',
> 'delete option --single-version-externally-managed from install options'),
657a660,665
> if ignore_single_version_externally_managed:
> self.setup_env_vars = self.setup_env_vars + 'SVEMOPT="" '
> else:
> self.setup_env_vars = self.setup_env_vars + 'SVEMOPT="--single-version-externally-managed" '
>
>
953c961
< --no-compile --single-version-externally-managed \\
---
> --no-compile ${SVEMOPT} \\
959c967
< --no-compile --single-version-externally-managed --install-layout=deb \\
---
> --no-compile ${SVEMOPT} --install-layout=deb \\
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
2009/9/23 Andrew Straw : > > Well, it wouldn't be setting a precedent that importing a module would > extend the functionality of the stdlib's distutils commands -- the > setuptools and distribute projects already do this. For example, the > "sdist" command in setuptools has many differences with that of "sdist" > in plain distutils. The point is that a user can choose not to import > setuptools and thus not get the different behavior. > > The case here is that if the stdlib ever grows bdist_deb, that's fine, > but I don't see why that should prevent stdeb from implementing a > bdist_deb command of its own. In this case, I think the issue is even > less relevant, since there is no stdlib "bdist_deb" command. Users would > naturally expect "bdist_deb" to do exactly what stdeb is implementing. > As long as I'm going ahead an implementing the functionality (which I'm > ambivalent about in and of itself for previously stated reasons), I > think it should be named the most obvious name. > During last Pycon summit, we v'e said that part of the problem with Distutils was that it was doing too much things and that we should probably try to remove all platform-specific commands to reduce its scope. For instance, bdist_rpm is fine, but being located in Python stdlib, its release cycle is too long, and it would probably be better for it to be on its own, managed by people from the "rpm community" (if this term makes sense, e.g. Fedora guys maybe ?) Same thing goes with bdist_deb : while it's more controversial to remove existing bdist_* command, we will not include new bdist_* commands for sure in Distutils, and rather let the debian/ubuntu community provide the best packaging solution on the top of Distutils. That said, if stdeb provides a plain Distutils command, that doesn't use Setuptools and if that command is stable and used in the community, we will be happy to add a pointer to it in Distutils documentation. The problem of using Setuptools or Distribute in a command is that it does a lot of patching (much more that overriding distutils sdist command) and that changes Distutils global behavior. Notice that the Distribute project plans to remove that patching in the future. Notice also that Distutils has a plugin system, where you can point a package that contains extra commands. This configuration can be done in distutils.cfg. This allows the usage of the command in the CLI without having to import the command directly in the setup.py file. Last, about the name, I think using "bdist_deb" is fine imho. If another project uses the same name, it's juste a matter of configuring the one to be used in a given context. Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Tarek Ziadé wrote: 2009/9/23 Andrew Straw : Well, it wouldn't be setting a precedent that importing a module would extend the functionality of the stdlib's distutils commands -- the setuptools and distribute projects already do this. For example, the "sdist" command in setuptools has many differences with that of "sdist" in plain distutils. The point is that a user can choose not to import setuptools and thus not get the different behavior. The case here is that if the stdlib ever grows bdist_deb, that's fine, but I don't see why that should prevent stdeb from implementing a bdist_deb command of its own. In this case, I think the issue is even less relevant, since there is no stdlib "bdist_deb" command. Users would naturally expect "bdist_deb" to do exactly what stdeb is implementing. As long as I'm going ahead an implementing the functionality (which I'm ambivalent about in and of itself for previously stated reasons), I think it should be named the most obvious name. During last Pycon summit, we v'e said that part of the problem with Distutils was that it was doing too much things and that we should probably try to remove all platform-specific commands to reduce its scope. For instance, bdist_rpm is fine, but being located in Python stdlib, its release cycle is too long, and it would probably be better for it to be on its own, managed by people from the "rpm community" (if this term makes sense, e.g. Fedora guys maybe ?) Same thing goes with bdist_deb : while it's more controversial to remove existing bdist_* command, we will not include new bdist_* commands for sure in Distutils, and rather let the debian/ubuntu community provide the best packaging solution on the top of Distutils. That said, if stdeb provides a plain Distutils command, that doesn't use Setuptools and if that command is stable and used in the community, we will be happy to add a pointer to it in Distutils documentation. The problem of using Setuptools or Distribute in a command is that it does a lot of patching (much more that overriding distutils sdist command) and that changes Distutils global behavior. Notice that the Distribute project plans to remove that patching in the future. Notice also that Distutils has a plugin system, where you can point a package that contains extra commands. This configuration can be done in distutils.cfg. This allows the usage of the command in the CLI without having to import the command directly in the setup.py file. Last, about the name, I think using "bdist_deb" is fine imho. If another project uses the same name, it's juste a matter of configuring the one to be used in a given context. Regards Tarek So are you saying then that a stddeb-based 'bdist_deb' should be implemented as a standalone plugin to Distribute? And how would that work for distros such as Ubuntu 8.0.4 Hardy? Would they be able to take advantage of Distribute? Regards, Gerry ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry Reno wrote: Tarek Ziadé wrote: 2009/9/23 Andrew Straw : Well, it wouldn't be setting a precedent that importing a module would extend the functionality of the stdlib's distutils commands -- the setuptools and distribute projects already do this. For example, the "sdist" command in setuptools has many differences with that of "sdist" in plain distutils. The point is that a user can choose not to import setuptools and thus not get the different behavior. The case here is that if the stdlib ever grows bdist_deb, that's fine, but I don't see why that should prevent stdeb from implementing a bdist_deb command of its own. In this case, I think the issue is even less relevant, since there is no stdlib "bdist_deb" command. Users would naturally expect "bdist_deb" to do exactly what stdeb is implementing. As long as I'm going ahead an implementing the functionality (which I'm ambivalent about in and of itself for previously stated reasons), I think it should be named the most obvious name. During last Pycon summit, we v'e said that part of the problem with Distutils was that it was doing too much things and that we should probably try to remove all platform-specific commands to reduce its scope. For instance, bdist_rpm is fine, but being located in Python stdlib, its release cycle is too long, and it would probably be better for it to be on its own, managed by people from the "rpm community" (if this term makes sense, e.g. Fedora guys maybe ?) Same thing goes with bdist_deb : while it's more controversial to remove existing bdist_* command, we will not include new bdist_* commands for sure in Distutils, and rather let the debian/ubuntu community provide the best packaging solution on the top of Distutils. That said, if stdeb provides a plain Distutils command, that doesn't use Setuptools and if that command is stable and used in the community, we will be happy to add a pointer to it in Distutils documentation. The problem of using Setuptools or Distribute in a command is that it does a lot of patching (much more that overriding distutils sdist command) and that changes Distutils global behavior. Notice that the Distribute project plans to remove that patching in the future. Notice also that Distutils has a plugin system, where you can point a package that contains extra commands. This configuration can be done in distutils.cfg. This allows the usage of the command in the CLI without having to import the command directly in the setup.py file. Last, about the name, I think using "bdist_deb" is fine imho. If another project uses the same name, it's juste a matter of configuring the one to be used in a given context. Regards Tarek So are you saying then that a stddeb-based 'bdist_deb' should be implemented as a standalone plugin to Distribute? And how would that work for distros such as Ubuntu 8.0.4 Hardy? Would they be able to take advantage of Distribute? I think a long term goal should be getting away from the plugin nature of distutils. I don't see why distutils (or my mythical distlib) shouldn't just be a package (or more likely multiple packages) that stand-alone tools can use. Other than much complexity and confusion, I don't see what plugins have bought us. Not everything (and especially not distutils) needs to be a framework. I'll admit that this plan in years down the road, at best. And it's not anyone's official position. Eric. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Gerry: >> So are you saying then that a stddeb-based 'bdist_deb' should be >> implemented as a standalone plugin to Distribute? And how would that work >> for distros such as Ubuntu 8.0.4 Hardy? Would they be able to take >> advantage of Distribute? Yes, it's just a matter of packaging this command in a standalone distribution. Once it's installed, and distutils.cfg properly configured, it can be used as a plugin. Distribute is not yet a good citizen for being used in such packages, because it still patches distutils like setuptools does. Eric: > I think a long term goal should be getting away from the plugin nature of > distutils. I don't see why distutils (or my mythical distlib) shouldn't just > be a package (or more likely multiple packages) that stand-alone tools can > use. Other than much complexity and confusion, I don't see what plugins have > bought us. Not everything (and especially not distutils) needs to be a > framework. It's just a matter of defining *where* is the CLI and how it works. The plugin system here is just to make those commands reachable from distutils's setup.py machinery. If another package has its own CLI, it can ignore this plugin system I guess. > > I'll admit that this plan in years down the road, at best. And it's not > anyone's official position. > Agreed, we need to think about alternatives. but in any case, nowadays, if the stdeb project wrap its work in a bdist_deb command that can be used as a distutils plugin, I don't think it's a problem for the future. I would be pretty happy about it :) Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] stdeb-0.3 error
Tarek Ziadé wrote: Gerry: So are you saying then that a stddeb-based 'bdist_deb' should be implemented as a standalone plugin to Distribute? And how would that work for distros such as Ubuntu 8.0.4 Hardy? Would they be able to take advantage of Distribute? Yes, it's just a matter of packaging this command in a standalone distribution. Once it's installed, and distutils.cfg properly configured, it can be used as a plugin. Distribute is not yet a good citizen for being used in such packages, because it still patches distutils like setuptools does. Eric: I think a long term goal should be getting away from the plugin nature of distutils. I don't see why distutils (or my mythical distlib) shouldn't just be a package (or more likely multiple packages) that stand-alone tools can use. Other than much complexity and confusion, I don't see what plugins have bought us. Not everything (and especially not distutils) needs to be a framework. It's just a matter of defining *where* is the CLI and how it works. The plugin system here is just to make those commands reachable from distutils's setup.py machinery. If another package has its own CLI, it can ignore this plugin system I guess. I'll admit that this plan in years down the road, at best. And it's not anyone's official position. Agreed, we need to think about alternatives. but in any case, nowadays, if the stdeb project wrap its work in a bdist_deb command that can be used as a distutils plugin, I don't think it's a problem for the future. I would be pretty happy about it :) Tarek Then I'm ok then with having 'bdist_deb' be the name and using the plugin approach. Andrew, what do you think about this solution? Regards, Gerry ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
