On Saturday, 2010-01-09, at 11:47 , Brad Allen wrote:
Now I understand that your 'project' concept probably corresponds
to an entry in PyPI which is associated with multiple releases
Yep. Or actually the project is the thing that a few hackers like
to spend their time on. It is the thing
On Thursday, 2010-01-07, at 20:43 , John Gabriele wrote:
So, here's a suggestion: just call both things (packages and
distributions) packages, but then agree to fully qualify the
names when you need to avoid ambiguity, for example: I just built
a distribution-package (or dist-package for
Michael:
Either one will probably work fine. The only differences at this
point (setuptools 0.6c10 prerelease and distribute 0.6.4) are which
issues have been fixed and how they were fixed. Also they are drop-
in replacements for one another, so you can try one and then switch
to the
On Monday,2009-10-12, at 14:25 , P.J. Eby wrote:
(E.g., one of the changes I made fixes three superficially
unrelated issues in the setuptools bug tracker.)
That would be:
http://bugs.python.org/setuptools/issue17
and
http://bugs.python.org/setuptools/issue65
Right?
What was the third?
On Friday,2009-10-09, at 6:25 , Benji York wrote:
On Thu, Oct 8, 2009 at 6:40 PM, Zooko Wilcox-O'Hearn
zo...@zooko.com wrote:
What we do in the Tahoe-LAFS project is we don't count down to a
future
version, we only count up from a past version. This is also what
Twisted
does
On Thursday,2009-10-08, at 15:41 , Ian Bicking wrote:
So after creating, say, version 0.3.1, I always mark a package as
0.3.2dev. But this is annoying, you might never create a version
0.3.2 (e.g., 0.4 might be the next level).
So, it would be better to use something like 0.3.1~dev. What
On Monday,2009-10-05, at 7:38 , Barry Warsaw wrote:
I apologize for my part in this, but moving forward I think that if
it's possible to patch and release a setuptools that works with
Python 2.6.3 /and/ earlier Python 2.6.x's, then that should happen
asap. If that's not possible, then we
On Monday,2009-10-05, at 8:11 , Tarek Ziadé wrote:
So are you saying that in an environment where you are allowed to
install Python 2.6.3, you will not be allowed to install an
hypothetical setuptools-0.6c10 (or a Distribute 0.6.3) ?
Yes, situations like that can come up. For example, I
I'm sorry to follow-up to my own post, but I realized that I didn't
make something clear: the current Tahoe-LAFS source distribution
comes with its own copy of setuptools, so even if PJE releases a new
version of setuptools or if we patch that copy to work-around this
problem, we're going
I'm struggling to articulate something here. When the maintainer of
the stable branch of a platform that I rely on says The fact that
upgrading to our recent stable release will break this critical
functionality is so-and-so's fault, not ours. this reduces my
confidence in that
On Sunday,2009-09-27, at 3:46 , Jeremy Sanders wrote:
distutils compiles C++ files with gcc (not g++) and uses invalid
compiler arguments on this Ubuntu system.
This setup.py works to build C++ files on Ubuntu:
http://allmydata.org/trac/pycryptopp/browser/setup.py
I'm not sure that you
-compatible build extensions to be accepted by
Glyph. This requires that they be testable. Please help me
understand how to write build extensions which are testable.
Regards,
Zooko
On Sunday,2009-08-16, at 14:16 , Zooko Wilcox-O'Hearn wrote:
Folks:
I have a recurring problem
On Wednesday,2009-07-22, at 9:52 , Brian Sutherland wrote:
van.pydeb is designed to be run at package build time, rather than
at the time you create the source package. I assume that's when
stdeb's code runs? Using apt-file during package build time on one
of the Debian project's
Folks:
I have been keeping a running tally of people who have trouble with
zipped eggs and the trouble goes away when they have unzipped eggs
instead. I just added the newest entry: someone was trying to build
a package with py2exe, and configuring their distutils config file to
always
The downloads count on http://pypi.python.org/pypi/setuptools suggest
that Python 2.4 is still slightly more popular than Python 2.5 among
non-Windows users who download their setuptools from pypi.
My TahoeLAFS project, which I hope will be an early adopter of
Distribute, I mean
On Jul 10, 2009, at 7:24 AM, Barry Warsaw wrote:
On Jul 10, 2009, at 8:58 AM, Marius Gedminas wrote:
1) put __version__ = '4.2' in yourpackage/__init__.py, have setup.py
do from yourpackage import __version__ and pass that to setup()
This is generally what I do and it seems to work
Barry:
What is the download cache?
I have a guess. If you are installing with the setuptools install
command, then the things which are install_requires get installed
into some target location, but things which are build_requires get
installed into the PWD. (If you don't specify a
On Jun 17, 2009, at 15:07 PM, Trent Mick wrote:
The tradeoff is that .zip files are compressed as well. But I don't
believe that difference in compression size
between .zip/.tar.gz/.tar.bz2 is that big of a concern in *most*
cases because most Python sdist's are small, are they not?
My
Trent Mick:
Thank you very much for the summary emails.
On Jun 9, 2009, at 1:58 AM, Trent Mick wrote:
# Super simple
...
major.minor.patch
...
# But I want to do an alpha release!
I don't think I'm overstating in saying that most of us (those that
care to help in defining Python
On Jun 11, 2009, at 2:37 AM, Paul Moore wrote:
1. From your description of events, and from discussion here, the
post tag is clearly the least thought through aspect of all this.
So a proponent of this should step up to justify why 1.0.5.post3 is
required, when 1.0.5.3 is available
If the rational version number spec allows arbitrary alphanumeric
components, then I can write something like $MAJ.$MIC.$MIN.snapshot
$COUNT. Any tool which wants to compare my version numbers to each
other will do the right thing -- newer snapshots are higher than
older snapshots,
On Jun 5, 2009, at 12:22 PM, Gerry Reno wrote:
Has there been any progress on getting the 'bdist_deb' target (akin
to 'bdist_rpm') implemented in Distutils? We are looking for
behavior that would be similar to bdist_rpm driven by setup.cfg
with fully automated generation of packages. There
On May 19, 2009, at 12:21 PM, Jean-Paul Calderone wrote:
What is the recommendation for specifying version information in a
way which is compatible with all these new tools?
My personal recommendation is to put the version information in a
flat text file and have your setup.py read that
23 matches
Mail list logo
