Suddenly, for no reason I know of, things are now working for me with pypy
on the pybuild-dev branch of stdeb.
On Fri, Mar 20, 2015 at 2:16 PM, Andrew Straw dr.andrew.st...@gmail.com
wrote:
Dear Stuart,
I just spent a little time unsuccessfully trying to get stdeb to build
.debs for pypy
Dear Stuart,
I just spent a little time unsuccessfully trying to get stdeb to build
.debs for pypy on the the pybuild-dev branch. If you want to play around,
that's where I'd start. Perhaps it's something simple I overlooked.
Best,
Andrew
On Tue, Mar 3, 2015 at 4:02 AM, Stuart Longland
On 5 Sep 2014, at 9:52 AM, Reinout van Rees rein...@vanrees.org wrote:
So... that's why Wheels started to sound nice. And compiling wheels yourself
and placing them on a server in a directory with various wheels for a
specific distribution... Sounds like the most standard option right now.
On 3 Sep 2014, at 12:24 PM, Reinout van Rees rein...@vanrees.org wrote:
b) Making a bunch of wheels seems like a nice solution. Then you can just use
a virtualenv and pip install numpy gdal psycopg2 But how do you
differentiate between ubuntu versions? Not every wheel will work with
On 3 Sep 2014, at 1:17 PM, Andrew Straw straw...@astraw.com wrote:
On 3 Sep 2014, at 12:24 PM, Reinout van Rees rein...@vanrees.org wrote:
b) Making a bunch of wheels seems like a nice solution. Then you can just
use a virtualenv and pip install numpy gdal psycopg2 But how do you
Hi all,
stdeb is a package to produce Debian packages from Python packages. Today I’m
announcing release 0.8.1 of stdeb. (Due to bugs in 0.8.0, this release is the
first announced from the 0.8 series.) Highlights since 0.7.1:
Full support for Python 3. This includes being run from Python 3
Hi all,
stdeb is a package to produce Debian packages from Python packages. Today I’m
announcing release 0.7.1 of stdeb. Highlights since the last publicly announced
release (0.6.0):
• New command-line commands: pypi-download and pypi-install to directly
download and install packages from
On 06/30/2010 11:48 PM, lukshun...@gmail.com wrote:
I'm using stdeb in debian/sid and the control file it generates
defaults to build-depends on python-all-dev. What should I do to make
it (build-)depend on python-dev? I've tried the --xs-python-version
option but I got python-all-dev all the
Barry Warsaw wrote:
I'm wondering if you've released a version with the debianize command, and if
not when you might do that. I'd like to work on getting that available in
Debian, Ubuntu, and my PPA.
I have just released stdeb 0.6.0 which has the debianize command. Thanks
for the testing,
I am moving the venue for this discussion on stdeb to the distutils-sig
(from http://bugs.python.org/issue1054967 ). I think this is better
discussed here.
On 4/29/10 9:23 PM, Barry A. Warsaw wrote:
Manual moving/copying is what I want to avoid. I'd be totally happy with not
reinventing
I am moving the venue for this discussion on stdeb to the distutils-sig
(from http://bugs.python.org/issue1054967 ). I think this is better
discussed there.
On 4/29/10 10:16 PM, Éric Araujo wrote:
Éric Araujomer...@netwok.org added the comment:
Andrew, I am uncomfortable with stdeb.
Manlio Perillo wrote:
Hi.
I would like to use support to namespace packages in setuptools, however
I have some doubts.
* will this feature be supported for future setup tools?
* is it efficient to use?
I have heard that it is slow if you're operating on NFS, as it causes
lots more
K. Richard Pixley wrote:
Andrew Straw wrote:
dpkg-gencontrol: warning: unknown substitution variable ${python:Provides}
dpkg-gencontrol: warning: unknown substitution variable ${python:Depends}
dpkg-gencontrol: warning: unknown substitution variable ${python:Provides}
dpkg-gencontrol: warning
K. Richard Pixley wrote:
What is the expected work flow around package dependencies between
python packages and debs in stdeb?
I was expecting it to declare any deb dependencies found, then
translate any python dependencies into the names they would have if
those pypi packages were
K. Richard Pixley wrote:
Andrew Straw wrote:
What I'm seeing with stdeb-0.5.1 is that no dependencies are declared
at all, but instead, I'm seeing unresolved macro references to
${python:Depends}.
What exactly is the error? Can you post the traceback or other error?
python-support
Chris Withers wrote:
I'm +1 on the branch having a version of 1.6.3~dev after 1.6.3 has
been released, and I like 2.0.0pre1 too :-)
I'm -1 on ~ meaning afterwards, because in Debian package versions it
means the exact opposite.
-Andrew
___
for these and previous releases:
Authors
---
* Andrew Straw straw...@astraw.com
* Pedro Algarvio, aka, s0undt3ch u...@ufsoft.org
* Gerry Reno (initial bdist_deb implementation)
Additional Credits
--
* Zooko O'Whielacronx for the autofind-depends patch
* Brett (last name unknown
Gerry Reno wrote:
Andrew,
I see in the latest postings where setuptools is breaking with Python
2.6.3. Can you switch 'stdeb' over to using Distribute, which is being
actively maintained?
As I understand it, installing Distribute installs a package called
setuptools. Therefore, my
Gerry Reno wrote:
I have attached a replacement 'bdist_deb.py' file that permits passing
arguments to bdist_deb which in turn passes them down to sdist_dsc.
and a util.py diff (made against the gerry-reno git branch) makes the
setup_env_vars work for both the line statements as well as the
Olof Bjarnason wrote:
OK I came a little further apt-get:ing debhelper and python-all-dev,
then issuing
sudo python -c import stdeb; execfile('setup.py') bdist_deb
.. but it ended with this:
dpkg-deb - fel: (upstream) version (dev) innehåller inga siffror
The English translation of
Gerry Reno wrote:
Andrew Straw wrote:
Gerry Reno wrote:
I have attached a replacement 'bdist_deb.py' file that permits passing
arguments to bdist_deb which in turn passes them down to sdist_dsc.
and a util.py diff (made against the gerry-reno git branch) makes the
setup_env_vars work
Gerry Reno wrote:
Andrew Straw wrote:
Gerry Reno wrote:
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?
It's already committed as of a couple days ago in the old-stable
branch and I just merged
Gerry Reno wrote:
Andrew Straw wrote:
Gerry Reno wrote:
Andrew Straw wrote:
Gerry Reno wrote:
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?
It's already committed
Olof Bjarnason wrote:
2009/9/28 Gerry Reno gr...@verizon.net:
Just pass the arguments directly to sdist_dsc. It should be something
like this:
python setup.py sdist_dsc --ignore-single-version-externally-managed
--ignore-install-requires bdist_deb
How's that going to work? You
Gerry Reno wrote:
Olof Bjarnason wrote:
Ok, the commands behave like makefile rules, once run they don't run
again.
But there are still several issues here:
Remember that I said that my goal with 'bdist_deb' was for users to
have a
SINGLE command to generate a .deb.
What needs to be
Olof Bjarnason wrote:
2009/9/28 Olof Bjarnason olof.bjarna...@gmail.com:
2009/9/28 Andrew Straw straw...@astraw.com:
Gerry Reno wrote:
Olof Bjarnason wrote:
Ok, the commands behave like makefile rules, once run they don't run
again.
But there are still several
Gerry Reno wrote:
What if stdeb only had the command 'bdist_deb' and had no other command.
I will not remove the sdist_dsc command from stdeb. I believe that the
ability to produce debian source packages is much more important that
the ability to produce binary packages which only target a
Gerry Reno wrote:
Andrew Straw wrote:
Gerry Reno wrote:
What if stdeb only had the command 'bdist_deb' and had no other
command.
I will not remove the sdist_dsc command from stdeb. I believe that the
ability to produce debian source packages is much more important that
the ability
Olof Bjarnason wrote:
Hi distutils!
So I'm quite sure stdeb is the tool for py2deb I'm looking for.
What are the correct steps of installing this tool, assuming
Ubuntu9.04. I guess I need this:
1. Python (check)
2. distutils (check)
3. setuptools (dunno? how do I install?)
4. stdeb (how
Olof Bjarnason wrote:
Um ok but I already got setuptools now. Should I install distribute too?
No, distribute has not been tested with stdeb yet. (To my knowledge.)
-Andrew
___
Distutils-SIG maillist - Distutils-SIG@python.org
Andrew Straw wrote:
Olof Bjarnason wrote:
Hi distutils!
So I'm quite sure stdeb is the tool for py2deb I'm looking for.
What are the correct steps of installing this tool, assuming
Ubuntu9.04. I guess I need this:
1. Python (check)
2. distutils (check)
3. setuptools (dunno? how do I
Olof Bjarnason wrote:
2009/9/26 Zooko Wilcox-O'Hearn zo...@zooko.com:
On Friday,2009-09-25, at 2:23 , Olof Bjarnason wrote:
I've skimmed a couple of tutorials on how to generate .deb-files, but,
wow, it's a whole new skill set to do that!
Have you tried stdeb?
Olof Bjarnason wrote:
OK thanks. I gather stdeb does handle .deb-package dependencies, like
PyGame, right?
Yes, you have to add them as a config option. See the Depends config
option in Customizing the produced Debian source package (config
options) in the README.
-Andrew
Gerry Reno wrote:
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?
It's already committed as of a couple days ago in the old-stable
branch and I just merged it into the master branch.
I'll release 0.3.1 (from
Gerry Reno wrote:
Andrew,
Here's another patch attempt. Is this what you had in mind?
Regards,
Gerry
OK, I looked at this, and now I'm throughly confused by what you are
trying to do. Back to your big picture, as I understood it, you were
trying to avoid importing setuptools because you
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
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
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
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.
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
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
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
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
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
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
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
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
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...
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
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
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` \
I'm getting a similar issue (easy_install failing on sourceforge) when
trying to download Pyro:
$ easy_install -eb. Pyro
/usr/lib/python2.6/dist-packages/Pyrex/Compiler/Errors.py:17:
DeprecationWarning: BaseException.message has been deprecated as of
Python 2.6
self.message = message
Searching
Tarek Ziadé wrote:
Phillip,
What about blessing someone to review and commit the patch for svn 1.6
support (and maybe other patches)
and do a setuptools release ?
Regards
Tarek
What about the idea that the next release of setuptools move svn support
to a setuptools_svn plugin like the
zooko wrote:
However, it currently doesn't. Eggs built on Linux are named something
like py2.5-Linux-x86_64. To know whether such an egg would actually
work on your Linux system, you would also need to know whether the
Python was compiled with UCS-2 or UCS-4 internal unicode representation,
zooko wrote:
Yes, if you used symbols from any shared library in an extension
module, you'd need to know the version of that shared library. So it's
not just libc. This is the same on any OS, not just linux.
Wait a minute, an extension module built into the Python Standard
Library, you
Kent Tenney wrote:
On Thu, Apr 9, 2009 at 3:24 PM, Lennart Regebro rege...@gmail.com wrote:
On Thu, Apr 9, 2009 at 21:37, Kent Tenney kten...@gmail.com wrote:
Howdy,
Is there a recommended way to manage Debian system
packages with a buildout?
Do you mean make the buildout install .deb
=Andrew Straw straw...@astraw.com,
packages = ['simplepack']
)
And the other files are:
./simplepack/__init__.py (empty)
./simplepack/simplepack.py (has a single print statement)
The error I got was:
$ ~/py2.5/bin/python setup.py bdist_wininst
running bdist_wininst
running build
running
Sridhar Ratnakumar wrote:
Is it possible to get the value of install_requires for an arbitrary
package without having to parse setup.py?
I see that --name, --version, --description, --provides, and so on are
available as an argument to setup.py, but --install-requires is missing.
Why?
Larry Hastings wrote:
I'm trying to add a lightweight virtualenv to a local build system
using PYTHONUSERBASE. Unfortunately the package maintainers for
distutils and setuptools broke it on my Ubuntu laptop.
Then you should file a bug report at
The latest version of stdeb, the automated Debian (and Ubuntu) package
maker, is available for download.
Stdeb takes your Python source (either a tarball or an a directory with
a setup.py script) and turns it into a Debian source package. From
there, it is trivial to turn it into a .deb file.
Hot on the heels of stdeb 0.2.2 comes 0.2.3. More fantastic features for
this Python-package-to-debian-package automator, you ask? Only one, a
--ignore-install-requires option added by Brett (last name unknown).
More importantly, however, are a couple bugfixes from Brett and Zooko
O'Whielacronx
that I'm
accomplishing the same goal using setuptools develop command with a
--prefix= option.
I just tested the new stdeb 0.2.3 at the request of Andrew Straw, and
it was able to produce a .deb from the allmydata-tahoe source tree. I
intend to configure some buildbots to automatically run
Tarek Ziadé wrote:
But note that being able to build .deb packages from another system
than debian could
be a great feature when doable.
Yes, that's true. To produce nice .debs, though you'd have to
re-implement a lot of the Debian packaging tools. Probably it's easier
just to run a chroot
stdeb (setuptools debian) produces Debian source packages from Python
packages via a new distutils command, sdist_dsc. Automatic defaults are
provided for the Debian package, but many aspects of the resulting
package can be customized via a configuration file.
This new release, 0.2.2, adds
I'm not sure if this will work, but it might:
class NotPlatformDependentDistribution(Distribution):
# Force platform-independent build.
def has_ext_modules(self):
return False
setup(
distclass = NotPlatformDependentDistribution,
)
Andreas Klöckner wrote:
Hi there,
:
Hi Andrew,
On Mittwoch 02 Juli 2008, Andrew Straw wrote:
I'm not sure if this will work, but it might:
class NotPlatformDependentDistribution(Distribution):
# Force platform-independent build.
def has_ext_modules(self):
return False
setup(
distclass
I would like to announce the release of stdeb 0.2.
= What is it? =
stdeb http://stdeb.python-hosting.com/ (setuptools debian) produces Debian
source packages from Python packages via a new distutils command, sdist_dsc,
which produces a Debian source package of a Python package. Automatic
Jean-Paul Calderone wrote:
On Sat, 26 Apr 2008 03:49:34 -0700, Andrew Straw [EMAIL PROTECTED]
wrote:
I would like to announce the release of stdeb 0.2.
Cool. I gave this a try on Twisted. Here's what I found:
Thanks for testing and, better, reporting your feedback.
* dpkg-buildpackage
In setuptools 0.6c5, a broken symlink in the package tree will cause
'setup develop' to fail, even in the file is inconsequential for the
package. I think this is a bug.
Here is the output of running python setup.py develop in a package
called flydra with a broken symlink called broken.symlink:
OK, I attach a fairly minimal python package. It builds fine normally.
Now, if you add a broken symlink in the source tree, it fails to build.
For example, ln -s /broken broken.symlink in the same directory as
setup.py.
Phillip J. Eby wrote:
At 12:23 PM 6/25/2007 -0700, Andrew Straw wrote
Phillip J. Eby wrote:
What platform are you on?
Ubuntu GNU/Linux: both 6.10 x86_64 Python 2.4 as well as 7.04 i686
Python 2.5.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Tore Ferner wrote:
Andrew Straw wrote:
Dear Tore,
I think the issue you're having is that bzr-0.16 requires, syntax-wise,
Python 2.4 or greater, but your pycentral is configured to install
things for Python2.3. Specifically, the postinst file generated by
dh_pycentral calls each Python
I would like to announce the release of stdeb 0.2.a1.
= What is it? =
stdeb http://stdeb.python-hosting.com/ (setuptools debian) produces
Debian source packages from Python packages via a new distutils command,
sdist_dsc, which produces a Debian source package of a Python package.
Automatic
Bob Ippolito wrote:
On 3/18/07, Christopher Armstrong [EMAIL PROTECTED] wrote:
On 3/18/07, Bob Ippolito [EMAIL PROTECTED] wrote:
I've just added a small optional C extension to simplejson to speed up
decoding, but I have a feeling that it's going to cause problems for
Windows users.
I'm trying to include shared libraries (built by scons invoked from my
setup.py script) into built eggs. I can do this just fine with the
package_data command, but then the egg isn't known to be platform
dependent. This is somewhat puzzling, because setuptools notices the
library and lists it
Phillip J. Eby wrote:
Of course, since it is such a useful and sensible idea, it will of course
be incompatible with Debian Python policy.
Sadly, that isn't a joke, as I'm sure there will be screams of bloody
murder regarding the idea of putting headers inside directories inside
Python
Phillip J. Eby wrote:
At 08:42 AM 7/4/2006 +0200, Matthias Klose wrote:
Phillip J. Eby writes:
what about installing the .egg-info directory without version
information when --single-version-externally-managed is used?
Note that the .pyc files will be built for a specific
Phillip J. Eby wrote:
At 11:20 AM 7/21/2006 -0700, Andrew Straw wrote:
Phillip J. Eby wrote:
At 02:49 PM 7/17/2006 -0700, Bob Ippolito wrote:
That's not a bad idea (update setup.cfg on sdist w/ --no-svn-
revision).
Any chance of getting this in setuptools 0.6 or should I
start adding
appreciate advice from Debian developers or Ubuntu MOTUs about the
arcane details of Python packaging.
License
---
MIT-style license. Copyright (c) 2006 stdeb authors.
See the LICENSE.txt file provided with the source distribution for
full details.
Authors
---
Andrew Straw, California
How do I do the equivalent of an exclude in MANIFEST.in using
setuptools? I can't find this documented anywhere.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Hi,
Attempting to use variable subsitition in my ~/.pydistutils.cfg file
(which I'd like to use across both Python 2.3 and Python 2.4), I find that
[install]
prefix=~/py$py_version_short-$PLAT
works fine
while the $variables in
[easy_install]
Phillip J. Eby wrote:
At 11:50 PM 1/23/2006 -0800, Andrew Straw wrote:
I would like to propose a feature for setuptools: runtime enforcement of
dependencies specified at build time by setup.py. I appreciate that
pkg_resources.require('foo==1.0') works, but this requires a tedious
update
Phillip J. Eby wrote:
At 05:31 PM 1/11/2006 -0800, Andrew Straw wrote:
Is it possible to convince easy_install to grab extras specified in the
extras_require arguments to setup()? I know this probably isn't
something that should be on by default (that's why they're extras),
but it would
Hi,
Is it possible to convince easy_install to grab extras specified in the
extras_require arguments to setup()? I know this probably isn't
something that should be on by default (that's why they're extras),
but it would be nice to do something like:
easy_install some_package
Hi, on a just-installed Debian sarge AMD64 installation, I have the
following behavior, which looks similar to the issue discussed here:
http://mail.python.org/pipermail/python-dev/2005-September/056955.html
(Like the author of that message, I have also downloaded setuptools from
CVS, and also
85 matches
Mail list logo
