David Kim wrote:
I am running the OS X EPD distribution, which uses Enstaller (built on
setuptools). Could this have something to do with it?
Sorry, but yes, this is exactly the problem. EPD comes with Enstaller
instead of setuptools, and thus there is no installed project called
We're starting to try and distribute some pre-built binaries on Solaris
and have come across an issue with how pkg_resources / distutils
generates the platform specification when the distribution includes
Python extensions.
In particular, we'd like to distribute both x86 and amd64 (or x86_64)
Tarek Ziade wrote:
2009/1/31 Floris Bruynooghe floris.bruynoo...@gmail.com:
I'm leaning more and more toward this is actually a bug
with the distutils source on Solaris.
Yes, I agree now that it is a bug in distutils and I agree with your
fix. The if statement should check both that
Tarek Ziadé wrote:
On Mon, Feb 2, 2009 at 7:29 PM, Dave Peterson dpeter...@enthought.com wrote:
Hi Tarek,
It isn't clear to me if you fixed it already or were waiting for my patch,
but I just added issue 5132 to the Python issue tracker to document the
issue and provide a patch file
Floris Bruynooghe wrote:
Hi Dave
On Mon, Jan 26, 2009 at 06:48:06PM -0600, Dave Peterson wrote:
I am trying to build a number of projects that use Python extensions on
Solaris 10 and I've discovered that nothing with extensions will link
unless I explicitly pass in a '-L/path/to/python
Josselin Mouette wrote:
Le mercredi 01 octobre 2008 à 14:39 -0400, Phillip J. Eby a écrit :
To be clear, I mean here that a file (as opposed to a resource) is
something that the user is expected to be able to read or copy, or
modify. (Whereas a resource is something that is entirely
Chris Withers wrote:
[1] Anyone know how to get .tgz source builds on windows rather than
.zips?
Yes, do 'python setup.py sdist --formats=gztar'.
You can find this yourself by doing 'python setup.py sdist -h' which
will show (among other things):
Options for 'sdist' command:
--formats
Ian Bicking wrote:
Alberto Valverde wrote:
Alberto Valverde wrote:
[...]
Reading a comment on the philikon article
(http://philikon.wordpress.com/2008/06/26/is-there-a-point-to-distributing-egg-files/#comment-47),
I also notice that Enthought has done some work on this, it seems by
fixing
Stanley A. Klein wrote:
I was able to build rpms for Traits, Envisage, and related packages (e.g.,
TraitsGUI) for Fedora 7. However, when I tried to package Enable I ran
into the following problem: The tar.gz gets built as
Enable-3.0.0.dev-r21092.tar.gz, but when the rpm packager gets called
Hi Stan,
Stanley A. Klein wrote:
Dave -
I wasn't using the release alias. From what you say, I suppose I should.
If you're trying to build rpms for the equivalent of the released
sdist's and eggs, then yes, you definitely should. If you look at the
setup.cfg files in all ETS projects,
Phillip J. Eby wrote:
At 12:02 PM 8/4/2008 -0500, Dave Peterson wrote:
Phillip J. Eby wrote:
At 07:05 PM 7/30/2008 -0500, Dave Peterson wrote:
Am I missing something or is the following a bug whereby adding the
'.dev' tag is doing something weird?
from pkg_resources import
Phillip J. Eby wrote:
At 01:41 PM 8/4/2008 -0400, Alexander Michael wrote:
Again, attempting to offer up practical solutions. Edit the
setup.cfg's to drop the dev option in the release branches and update
the trunk to the next version (i.e. 3.1.dev-rX)? That way,
checkouts of the release
New submission from Dave Peterson [EMAIL PROTECTED]:
It would be convenient to be able to upload pre-built eggs using the 'python
setup.py upload' command as the owner/author of a project may not have machines
available to cover the platforms for which pre-built binaries are desired.
Having
Am I missing something or is the following a bug whereby adding the
'.dev' tag is doing something weird?
from pkg_resources import parse_requirement as pv
pv('1.0a1.dev') pv('1.0a1')
True
pv('1.0a1') pv('1.0')
True
pv('1.0a1.dev') pv('1.0.dev')
False
pv('1.0a1') pv('1.0.dev')
False
Phillip J. Eby wrote:
At 06:27 PM 6/16/2008 -0500, Dave Peterson wrote:
Phillip J. Eby wrote:
At 12:57 PM 6/16/2008 +1200, Greg Ewing wrote:
Any discussion of that sort seems to get hopelessly
bogged down, so bikeshedding is all that's left for
people to do.
What about testing patches
Phillip J. Eby wrote:
At 12:57 PM 6/16/2008 +1200, Greg Ewing wrote:
Any discussion of that sort seems to get hopelessly
bogged down, so bikeshedding is all that's left for
people to do.
What about testing patches? Writing test code? Writing more docs?
There's *plenty* of less
Gael Varoquaux wrote:
On Mon, Apr 14, 2008 at 01:30:14PM +1200, Greg Ewing wrote:
Gael Varoquaux wrote:
a second Python
needs to be installed on top of the system Python to add modules to it.
Maybe the system should come with two pythons installed,
one for use by the
Phillip J. Eby wrote:
At 03:48 PM 4/10/2008 -0500, Dave Peterson wrote:
Stanley A. Klein wrote:
On Wed, 2008-04-09 at 18:17 -0500, Dave Peterson wrote:
I think I can sum up any further points by simply asking: Should it
be safe to assume I can distribute my application via eggs
Jeff Rush wrote:
Dave Peterson wrote:
Phillip J. Eby wrote:
At 11:40 PM 4/1/2008 -0500, Dave Peterson wrote:
I've previously volunteered Enthought to do about the same thing (except
to include svn with the Trac instance) but there wasn't much response
beyond Jeff Rush saying he
Phillip J. Eby wrote:
At 11:40 PM 4/1/2008 -0500, Dave Peterson wrote:
I've previously volunteered Enthought to do about the same thing (except
to include svn with the Trac instance) but there wasn't much response
beyond Jeff Rush saying he was already setting one up, and the response
*From:* Dave Peterson [mailto:[EMAIL PROTECTED]
*Sent:* Wednesday, 2 April 2008 3:30 PM
*Cc:* Mark Hammond; distutils-sig
*Subject:* Re: [Distutils] [Python-Dev] How we can get rid of eggs for
2.6 and beyond
Mark Hammond wrote:
(Note: I'm aware that people believe it to be necessary
Mark Hammond wrote:
(Note: I'm aware that people believe it to be necessary to munge the
Windows registry when installing Python packages; I just don't agree
with the practice, and don't think we should distort Python's process
to coddle it).
Whoever thinks it necessary is misguided.
zooko wrote:
I would be willing to host a trac instance to serve as a wiki and
issue tracker for setuptools, and a buildbot. (But I don't want to
have anything to do with subversion -- I much prefer darcs.)
I've previously volunteered Enthought to do about the same thing (except
to
Jeff Rush wrote:
2. If we moved PyPI to serve exclusively over https, for integrity
reasons, would this have a major negative impact?
Given that urllib2 doesn't support https through a proxy, it would
probably cause a problem for easy_install, etc. :-)
We had to create a custom
Jeff Rush wrote:
Dave Peterson wrote:
I agree. Let's get that setuptools wiki started and start
documenting some of these ideas as a roadmap so that anyone who wants
to help out has an idea of what to work on, or factor into what
they're currently working on.
Anyway, since Enthought
Christian Heimes wrote:
[EMAIL PROTECTED] schrieb:
So, at the risk of painting a bike-shed, I'd like to propose that we adopt
'AMD64' in distutils (needs a change), platform.py (needs a change to use
sys.getwindowsversion() in preference to pywin32, if possible, anyway),
and the Python
I've added your comments to a wiki page
(http://wiki.python.org/moin/PackagingBOF) I was working on to summarize
some of what went on during these BoF meeting, at least from the
Enthought point-of-view. Unfortunately, I wasn't at the first night's
event and don't yet have Travis Oliphant's
Phillip J. Eby wrote:
At 05:10 PM 3/17/2008 -0500, Jeff Rush wrote:
1. Many felt the existing dependency resolver was not correct. They wanted a
full tree traversal resulting in an intersection of all restrictions,
instead of a first-acceptable-solution approach taking now, which
[EMAIL PROTECTED] wrote:
Any idea what the problem might be? I'm using easy_install 0.6c7 with
Python 2.6 (Subversion checkout). I don't know if 0.6c7 is the most recent
version or not.
Sorry, I've got no idea on the problem but I can answer your other
question. There is at least a
zooko wrote:
Following up to my own post:
On Jan 27, 2008, at 9:17 PM, zooko wrote:
One idea that I had was to run a query on the Python Package Index
database to find all packages whose setup.py's define entry points in
the distutils.commands group name.
Another was to put the word
Phillip J. Eby wrote:
At 12:03 PM 1/3/2008 -0600, Carl Karsten wrote:
Scripts are files containing Python source code, intended to be started from
the command line. http://docs.python.org/dist/node11.html
I want to do that. I am hoping that once it is done, it will be in
a dir that
is
Phillip J. Eby wrote:
At 05:09 PM 1/3/2008 -0200, phil jones wrote:
I take it there's nothing in distutils that can actually update the
user's OS PATH?
Nope.
This may not help in the general case, but if you have a more specific,
say customer delivery, issue then you might
Phillip J. Eby wrote:
At 05:00 PM 1/3/2008 -0600, Dave Peterson wrote:
Just curious, but is there a reason setuptools uses 'Scripts' on Windows
instead of the 'Tools' dir? Unless I'm mistaken, a a new install of
Python 2.5 puts scripts in 'Tools'.
It puts Python-supplied scripts there, yes
Robert Kern wrote:
Dave Peterson wrote:
Most of us here are not seeing this
error so I'm thinking it isn't something obviously wrong with the
setup.py. You can look at the setup.py at :
https://svn.enthought.com/enthought/browser/tags/enthought.interpolate_2.0.0b3/setup.py
Note
Dave Peterson wrote:
Phillip J. Eby wrote:
At 02:15 PM 12/6/2007 -0600, Dave Peterson wrote:
PPS: I do believe other users have reported the same issues on other
systems but we've never quite figured out what the cause is. IIRC,
telling them to manually download the source tarball
A user is trying to install Enthought's ETS projects on a Gentoo system
and getting the following error message. I'm not seeing it on my
systems, but then I'm not running Gentoo. Can anyone give me a clue as
to what might be happening or how to go about determining what is
happening? The
Phillip J. Eby wrote:
At 02:15 PM 12/6/2007 -0600, Dave Peterson wrote:
PPS: I do believe other users have reported the same issues on other
systems but we've never quite figured out what the cause is. IIRC,
telling them to manually download the source tarball and do a 'python
setup.py
Phillip J. Eby wrote:
At 10:37 AM 10/23/2007 -0400, Stanley A. Klein wrote:
On Mon, 2007-10-22 at 18:15 -0500, Dave Peterson wrote:
Stanley A. Klein wrote:
Other failures included:
endo - unpackaged pyc and pyo files (looks like a setup.py issue)
I get rpms built for this just
Phillip J. Eby wrote:
At 10:37 AM 10/23/2007 -0400, Stanley A. Klein wrote:
On Mon, 2007-10-22 at 18:15 -0500, Dave Peterson wrote:
Stanley A. Klein wrote:
Other failures included:
endo - unpackaged pyc and pyo files (looks like a setup.py issue)
I get rpms built for this just
We've gotten a number of problem reports from people trying to install
our egg releases where there doesn't seem to be enough information being
output to the console to really debug the problem. Here's an
illustrating log taken from a user's report:
===
C:\Documents and
What happens if a user specifies a URL via a '-f' option on the
easy_install command line but our published eggs specify
dependency_links in the setup.py? Will easy_install search the user's
specified location first, last, or will it not search them at all?
(I'm hoping for the first!)
Ryan May wrote:
Ryan May wrote:
On Thu, July 26, 2007 2:01 pm, Phillip J. Eby wrote:
At 01:37 PM 7/26/2007 -0400, Stanley A. Klein wrote:
I had the same error. Should I have put in an import enthought in all
the others?
No, apparently the manual import
Over on the enthought-dev mailing list we're having a bit of a
discussion on what the best way to distribute documenation and examples
is for projects that we distribute binary eggs for. The general
consensus is that it would be very nice indeed if there was a way to
generate a tarball, or
Stanley A. Klein wrote:
On Thu, July 26, 2007 12:46 pm, Phillip J. Eby wrote:
At 03:02 AM 7/26/2007 -0500, Dave Peterson wrote:
Over on the enthought-dev mailing list we're having a bit of a
discussion on what the best way to distribute documenation and examples
is for projects that we
Mark Hammond wrote:
A good value for 'architecture' isn't clear. Either 'AMD' or 'Itanium'
appeals at first glance, but I'm a little concerned that (say) a casual
user with a new Intel Core Duo processor will not know they should use
something labelled as AMD (eg, I explicitly asked for an
Hello,
I'm not sure if I've painted Enthought into a corner or not, but I can't
figure out if there is a way to help users of a library, delivered as an
egg, to know and/or maintain dependencies on extras declared in that
egg. By which I mean that if my library, called X, declares extras 1,
Phillip J. Eby wrote:
At 01:50 PM 7/20/2007 -0500, Dave Peterson wrote:
Hello,
I'm not sure if I've painted Enthought into a corner or not, but I can't
figure out if there is a way to help users of a library, delivered as an
egg, to know and/or maintain dependencies on extras declared
Phillip J. Eby wrote:
At 03:44 PM 7/18/2007 -0500, Dave Peterson wrote:
Hello,
Is there a blessed-as-stable, official, release of setuptools?
Perhaps it's just me but a version number of the form '0.6c6' or '0.7a1'
just doesn't seem like the developers think it is stable yet, even
48 matches
Mail list logo
