On Mar 28, 2013, at 02:22 PM, Donald Stufft wrote:
>Is there much point in keeping catalog-sig and distutils-sig separate?
Without yet reading the whole thread, I'll just mention that it's probably
easier to just retire one or the other mailing lists and divert all discussion
to the other one. O
On Mar 18, 2013, at 04:13 PM, Nick Coghlan wrote:
>Eventually I expect pip will grow a "--wheel-only" option to run it in
>strict "installer only" mode, but the ecosystem is a long way from
>supporting that being a useful option (especially since there are some
>cases which will still require fall
On Mar 18, 2013, at 02:16 PM, Lennart Regebro wrote:
>I still think it is unfortunate that we are starting to extend pip to
>be a tool for developers to create distributions. It would be better
>of pip was kept as an install tool, and we added the utilities for
>creating distributions separate.
+
On Mar 04, 2013, at 10:29 PM, Mark McLoughlin wrote:
>The approach that some Fedora folks are trying out is called "Software
>Collections". It's not Python specific, but it's basically the same as a
>virtual environment.
It's a serious problem, and I think it will be made more so by the incursion
On Mar 04, 2013, at 06:11 PM, Nick Coghlan wrote:
>My point of view is that the system Python is there primarily to run
>system utilities and user scripts, rather than arbitrary Python
>applications. Users can install alternate versions of software into
>their user site directories, or into virtua
On Nov 20, 2012, at 04:51 PM, Daniel Holth wrote:
>Bento uses these categories by default and lets you define your own. If
>requested by the package, it writes the install-time prefixes to a
>per-package .py file with NAME="value" lines.
The key thing about the categories idea is that distro main
On Nov 20, 2012, at 09:18 AM, Ronald Oussoren wrote:
>To be (too) snarky: because the FHS says so.
>
>Less snarky, Linux distributors try to keep simular files together (for
>example storing all gettext translations together in /usr/share/locale). To
>play nice in such an enviroment Python packa
I'm just beginning to review these PEPs and the threads, with an OS vendor
packager's eye. Let me start with one small suggestion for PEP 425.
From the FAQ:
Q. Who will maintain the registry of abbreviated implementations?
A. New two-letter abbreviations can be requested on the python-dev maili
On Oct 18, 2012, at 01:34 PM, Barry Warsaw wrote:
>You need to advertise it on python-dev to get some wider feedback.
Oops, I see you did that. Yay!
-Barry
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mail
On Oct 18, 2012, at 01:29 PM, Daniel Holth wrote:
>Let me know what I need to do to get it accepted, if anything needs to
>be added or revised, or, preferably, that it is awesome and you want
>to use it ASAP.
You need to advertise it on python-dev to get some wider feedback. Then ask
Guido wheth
On Oct 02, 2012, at 06:44 PM, Vinay Sajip wrote:
>Okay. Naturally there is already support for absolute paths in the file
>system for resources which are in the file system, so the question was really
>for resources in zips. Is it expected that the scenario will be quite common
>to get a .so or si
On Oct 01, 2012, at 03:43 PM, Vinay Sajip wrote:
>Barry Warsaw python.org> writes:
>> Why not provide this by distlib?
>
>Only because it doesn't add much value, and (if you do all that pkg_resources
>does) might mean that you have to maintain a cache.
Well, it's
On Oct 01, 2012, at 07:35 AM, Vinay Sajip wrote:
>Yes, I find that odd, too. pkg_resources seems to extract files from zip into
>a cache folder, then returns filenames from the location in the cache; it
>seems a lot of trouble to go to just to be able to deliver a filename.
Darn handy though when
On Sep 30, 2012, at 10:00 PM, Daniel Holth wrote:
>resource_filename is very popular. I would have thought
>resource_stream would be more popular. Unless your package is zipped
>resource_filename is trivial to implement.
I've used declare_namespace() once or twice.
I use resource_filename(), res
On Sep 28, 2012, at 12:01 PM, Éric Araujo wrote:
>I’m putting up a last-minute proposal for a panel about directions for
>the packaging ecosystem at the next PyCon. For that I would need a list
>of panelists. I think it would be interesting to have developers (say
>from distribute, buildout, pip
On Sep 16, 2012, at 03:40 PM, Chris McDonough wrote:
>On Sun, 2012-09-16 at 15:33 -0400, Daniel Holth wrote:
>> It is because the file has a controversial coding style, with up to 25
>> lines of whitespace between classes, and includes functionality for
>> eggs and some other stuff that was unwant
On Sep 16, 2012, at 03:33 PM, Daniel Holth wrote:
>It is because the file has a controversial coding style, with up to 25
>lines of whitespace between classes, and includes functionality for
>eggs and some other stuff that was unwanted on top of the resources
>stuff that partly made its way into p
On Sep 16, 2012, at 1:23 PM, Chris McDonough wrote:
> On Sun, 2012-09-16 at 08:07 -0400, Daniel Holth wrote:
>> Of course the major potentially non obvious caveats are that a lot of python
>> code doesn't use the API to load data from the importer path, instead using
>> __file__ and assuming eve
On Sep 07, 2012, at 11:52 PM, Maurits van Rees wrote:
>> PyPI says a new version of z3c.recipe.tags was uploaded today (2012-09-06).
>> It looks like a file was missing from the zip.
>
>Fixed and 0.6 released by Christian Theune. Thanks!
Looks great, thanks!
-Barry
signature.asc
Description:
The latest upload of z3c.recipe.tag appears to be broken. I'm sending this
message to zope-...@zope.org because that's the maintainer_email from the
setup.py, and I can't find any indication of where to submit bug reports. I'm
also CC'ing distutils-sig, just 'cause. :)
Doing a buildout of the Ma
On Apr 12, 2012, at 05:51 PM, Marius Gedminas wrote:
>Interesting. As a data point: I use zc.buildout 1.5.2 on Ubuntu 11.10.
>I haven't encountered any namespace issues yet.
I haven't seen any issues with zc.buildout 1.5.2 on Ubuntu 12.04 either.
Cheers,
-Barry
signature.asc
Description: PGP
On Feb 08, 2012, at 02:05 PM, Andrew McNabb wrote:
>I'm trying to use 2to3 in setup.py for the first time. I have
>distribute installed, so it sounds like I should be able to just add
>"use_2to3=True" to my call to setup, and things should just work.
>
>Unfortunately, the setup.py is currently im
On Oct 04, 2011, at 01:55 PM, Floris Bruynooghe wrote:
>You will have to do this in your application yourself: don't let a
>file be installed but create them at runtime. If you're following
>Debian policy (which you should) you should remove the created files
>in the postrm script of the Debian p
On Sep 28, 2011, at 09:59 AM, Greg Ewing wrote:
>Are there really no existing open-source mirroring
>systems out there?
rsync? :)
-Barry
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
On Sep 15, 2011, at 06:50 PM, Mac Ryan wrote:
>Thanks for this, sooner or later I will try again to have a crack at
>packaging "from the scratch" but so far I got lost in the many
>possible way one could do that... [I know - from the presentation you
>gave somewhere and I found on the intertubes -
On Jun 09, 2011, at 12:31 AM, Fred Drake wrote:
>(I think we agree on this, but language is tedious, since there are many
>casual uses of the term 'package' here, and 'namespace packages' aren't as
>commonly known outside particular segments of the community.)
I think "namespace package" is a pre
On Jun 08, 2011, at 10:47 PM, Fred Drake wrote:
>On Wed, Jun 8, 2011 at 6:14 PM, Barry Warsaw wrote:
>> #. For modules which live inside a namespace package, the sub-package
>> name SHOULD include the ``__version__`` attribute. The namespace
>> module itself SHOUL
On Jun 09, 2011, at 01:29 PM, Éric Araujo wrote:
>Yes, the PEP uses that field since I said I thought it could not reuse
>the version field; my email was meant to change “I think it should be
>another field” to “it must definitely be another field”.
>
>version-from-file is a good name if a regex i
On Jun 09, 2011, at 10:42 AM, Ben Finney wrote:
>Barry Warsaw writes:
>
>> #. The ``__version__`` attribute's value SHOULD be a string.
>
>I may be fighting against the tide here; but this screams to me that the
>PEP should not be talking at all about “version number”
Given Ben's and Fred's feedback, what do you think about this list in the
Specification's section:
#. In general, modules in the standard library SHOULD NOT have version
numbers. They implicitly carry the version number of the Python
release they are included in.
#. On a case-by-case basis
Hi Éric,
On Jun 07, 2011, at 05:30 PM, Éric Araujo wrote:
>Just two things I thought about while perusing my archives yesterday.
>
#. For modules which are also packages, the module namespace > SHOULD
include the ``__version__`` attribute.
>>>
>>> I’m still not sure “module n
On May 12, 2011, at 09:28 AM, Jim Fulton wrote:
>If you tell me that distribute is being actively maintained, I'll use
>distribute. What I've heard in the past is that distribute wasn't
>being worked on. I'd interpreted this to mean that it wasn't being
>maintained. Perhaps I misinterpreted. Again
On May 06, 2011, at 04:51 PM, Carl Meyer wrote:
>On 05/06/2011 04:43 PM, Carl Meyer wrote:
>> I don't quite understand this. On my Ubuntu system, with either Ubuntu's
>> Python 2.6 or my compiled 3.2, sys.path[0] appears to always be the
>> empty string, never the actual full path of the script's
On May 06, 2011, at 04:43 PM, Carl Meyer wrote:
>I don't quite understand this. On my Ubuntu system, with either Ubuntu's
>Python 2.6 or my compiled 3.2, sys.path[0] appears to always be the
>empty string, never the actual full path of the script's directory. How
>is it ever == '/usr/share/pyshare
On May 04, 2011, at 11:15 AM, Carl Meyer wrote:
>Virtualenv itself supports Python 2.4 - 3.2 from a single codebase,
>beginning with the 1.6 release a few weeks ago, thanks to Vinay Sajip.
>Try it out!
So I have some more information on this. Debian Wheezy has 1.6 now, but -p
python3 still did n
On May 04, 2011, at 09:36 PM, Laura Creighton wrote:
>If you want something that works with PyPy 1.5, you need 1.6.1 released
>on Saturday. 1.6 will not work.
Cool, thanks for the info. I've noticed that even the Debian version of 1.6
isn't being built for Python 3, so I'm going to see if I can
On May 04, 2011, at 11:15 AM, Carl Meyer wrote:
>Virtualenv itself supports Python 2.4 - 3.2 from a single codebase,
>beginning with the 1.6 release a few weeks ago, thanks to Vinay Sajip.
>Try it out!
>
>As far as I know neither virtualenv3 nor virtualenv5 will be developed
>anymore, as both were
What's the current status of virtualenv3? When I search the Cheeseshop, I get
two hits:
http://pypi.python.org/pypi?%3Aaction=search&term=virtualenv3&submit=search
It looks like Holger's virtualenv5 is a temporary fork of Brandon's
virtualenv3 port. The latter seems to work fine for me on Ubunt
On Apr 09, 2011, at 06:23 PM, Éric Araujo wrote:
> Glad to read my review helped :)
Indeed, thanks.
> I also think that “bundle” is a nice term to name what the docs
> currently calls a distribution.
At the very least, *bundle* isn't completely overloaded 10x over in Pythonland
yet. :)
An
On Mar 27, 2011, at 03:36 PM, Yannick Gingras wrote:
>On March 24, 2011, Éric Araujo wrote:
>> > Bob learns about the Cheeseshop [2]_, and adds some
>> > simple packaging using classic distutils so that he can upload *The
>> > Bob Package* to the Cheeseshop.
>> I know that the referenced PEP 345 c
Hi Éric,
Thanks for the feedback, and my apologies for the delay in responding.
On Mar 25, 2011, at 03:52 AM, Éric Araujo wrote:
>> `distutils2` [1]_) may be adapted to use the conventions defined here.
>Nit: I never rely on docutils/sphinx default role (using a bare `text`
>without explicit :ro
ve the
freedom to do whatever they want.
Cheers,
-Barry
PEP: 396
Title: Module Version Numbers
Version: $Revision: 65628 $
Last-Modified: $Date: 2008-08-10 09:59:20 -0400 (Sun, 10 Aug 2008) $
Author: Barry Warsaw
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 2011-03-16
Post
On Mar 20, 2011, at 01:18 AM, Leonardo Rochael Almeida wrote:
>Another variant of this case, one we're actually facing here at our
>company (Nexedi) right now, is when you need to compile extension
>modules with libraries that are newer than the ones in the system, and
>you don't have root access.
On Mar 18, 2011, at 10:37 AM, Carl Meyer wrote:
>Hmm, really? What extension does the executable typically have on OS X
>that ought to be stripped?
As others have pointed out, the OS X build leaves a python.exe in the
development tree, but installs without the .exe. I think it's useful to be
abl
Sounds good to me.
On Mar 17, 2011, at 07:53 PM, Carl Meyer wrote:
>* has the extension stripped on Windows, but not
>otherwise.
It should probably also have the extension stripped on OS X too.
-Barry
signature.asc
Description: PGP signature
___
Di
On Mar 17, 2011, at 05:33 PM, Carl Meyer wrote:
>On 03/17/2011 05:13 PM, Jim Fulton wrote:
>> I suggest the following:
>>
>> Look for argv[0]+'.pythonv' and then for '../pythonv.cfg'.
>>
>> So if I've linked the Python executable to ./bin/clean, look for
>> ./bin/clean.pythonv and ./pythonv.cfg.
On Mar 17, 2011, at 12:44 PM, Carl Meyer wrote:
>Any opinions on the commandline UI for this? I was thinking of just
>adding a "pythonv.py" to the stdlib that you could execute with "python
>-m pythonv path/to/new/env" (and would also export appropriate API to
>create environments programmatically
On Mar 17, 2011, at 02:50 PM, Carl Meyer wrote:
>On 03/16/2011 11:04 PM, Barry Warsaw wrote:
>> +1. Time for a PEP?
>
>Working on a draft PEP. I'll push it to bitbucket to make collaboration
>easier - then the next step would be to present the draft on
>python-i
On Mar 17, 2011, at 12:32 PM, Carl Meyer wrote:
>I also realized last night that if the need for LD_LIBRARY_PATH is as
>rare as it seems to be, people could just as well set it themselves
>before running stuff in their virtualenv. We could even have our shell
>"activate" script set it, so you'd on
On Mar 17, 2011, at 08:07 AM, Jim Fulton wrote:
>Whatever mechanism we end up with, I suggest that a standard python
>install include an isolated configuration. This is a common use case
>and should be available without having to create a virtualenv (or
>whatever) for each project or working direc
On Mar 17, 2011, at 08:36 AM, Fred Drake wrote:
>On Wed, Mar 16, 2011 at 10:39 PM, Barry Warsaw wrote:
>> I vaguely recall that while this *should* work, it actually doesn't
>> because once the executable has started, $LD_LIBRARY_PATH isn't consulted
>> again.
On Mar 16, 2011, at 10:33 PM, Carl Meyer wrote:
>I've pushed this symlink/copy binary approach to the "pythonv2" branch
>at http://bitbucket.org/carljm/cpythonv. I was a bit shocked at how easy
>it turned out to be: just a few lines in site.py and the same changes to
>sysconfig.py as previously. N
On Mar 16, 2011, at 07:19 PM, Carl Meyer wrote:
>This alternative approach (with a symlink and config file) sounds pretty good
>to me as well after our discussion at the sprints. The downsides I see:
>
>1. Cross-platform inconsistency. Windows virtualenvs would be isolated from
>system python bina
On Mar 16, 2011, at 12:21 PM, Brandon Craig Rhodes wrote:
>I certainly agree with everyone that Python 3.3 should natively support
>a virtualenv mechanism, but I think that it should be the full "python"
>that gets copied. I realize that this means that the "python" binary
>will not get updates w
On Mar 03, 2011, at 11:05 PM, Manlio Perillo wrote:
>It seems I'm having some trobles with setuptools and namespace packages
>under Debian Squeeze and Python 2.6.
Can you be more specific about what problems you're having?
>One thing to say about Python 2.6 on Debian Squeeze is that "local"
>pac
On Mar 07, 2011, at 05:18 PM, Jim Fulton wrote:
>Given that Python 3 is a reboot, maybe it's time for the Python
>community to start calling these what ``python`` calls them,
>"modules".
Very nice. +1. And "nested module" where the distinction is important. Even
"namespace module" sounds okay
Excellent idea Lennart...
On Mar 06, 2011, at 03:51 PM, Brad Allen wrote:
>cheeseshop.critic
>pypi.stickler
I like the cheeseshop namespace used for this. Or maybe wenslydale :)
http://orangecow.org/pythonet/sketches/cheese.htm
-Barry
signature.asc
Description: PGP signature
___
On Feb 25, 2011, at 10:27 AM, Mark Sienkiewicz wrote:
>Barry Warsaw wrote:
>> So, do you have any suggestions for a better way to say "never download
>> dependencies" for a particular package, or class of packages. easy_install
>> has (at least in distribute) a d
On Feb 23, 2011, at 02:25 PM, Toshio Kuratomi wrote:
>What Barry's talking about is slightly different I think. When running
>python setup.py test, setup.py may download additional modules that should
>have been specified in the system package (thus the download should never be
>tried). This occ
On Feb 19, 2011, at 12:57 AM, Éric Araujo wrote:
>Old thread revival! I was going through my archive and noticed this
>unanswered message from late September which prompted me to do a bit of
>research.
\o/
> However, upload_docs
> never quite works out of the box for me anyway. First,
Something that's come up recently in the Debian Python mailing list is
setuptools/distribute's habit of downloading *_requires packages
(e.g. install_requires) when they are not available locally.
This causes us problems because dependencies are defined in two places. They
are defined in setup.py
"/usr/lib/python3.2/doctest.py", line 1248, in __run
compileflags, 1), test.globs)
File "", line 1
print Colors.red
^
SyntaxError: invalid syntax
Any thoughts? Here's my setup():
setup(
name='flufl.enum',
version=__
On Dec 18, 2010, at 04:24 AM, Marius Gedminas wrote:
>On Fri, Dec 17, 2010 at 05:26:47PM -0500, Barry Warsaw wrote:
>> Something bugs me about virtualenv, distribute, development, and testing. I
>> figure I'm probably doing something wrong and that y'all will be a
On Dec 18, 2010, at 04:49 AM, Arfrever Frehtes Taifersar Arahesis wrote:
>2010-12-18 00:16:52 P.J. Eby napisał(a):
>> At 05:26 PM 12/17/2010 -0500, Barry Warsaw wrote:
>> >Something bugs me about virtualenv, distribute, development, and testing. I
>> >figure I'
Something bugs me about virtualenv, distribute, development, and testing. I
figure I'm probably doing something wrong and that y'all will be able to set
me straight.
I'm working on a new tool called pkgme[1]. It uses distribute and recommends
using virtualenv for development. After activating t
On Dec 15, 2010, at 10:05 AM, Sean Ochoa wrote:
>Hello all. I'm wondering if there is still any effort behind the stdeb
>package development. I find it super handy for what I do at work, and I'm
>wondering if there's going to be canonical support and/or further package
>development done in this
On Dec 10, 2010, at 01:42 PM, Brian Sutherland wrote:
>On Fri, Dec 10, 2010 at 07:17:16AM -0500, Barry Warsaw wrote:
>> The way zope.interface "owns" the zope namespace is not correct. Ideally,
>> there would be a separate binary package that owns zope/__init__.py and o
On Dec 10, 2010, at 09:36 AM, Brian Sutherland wrote:
>Please don't, this has been reported various times already.
>
>Removing the zope/__init__.py causes breakage in other places, as I
>detail in my response to your bug.
>
>I would guess that the real bug is at a deeper level.
Just a couple of t
On Dec 09, 2010, at 12:35 AM, Alan Franzoni wrote:
>On Wed, Dec 8, 2010 at 8:10 PM, Barry Warsaw wrote:
>> Why do we have symlinks in the first place? It's because Debian and Ubuntu
>> support multiple active versions of Python at the same time. Once Python 2
>> is
&
To start with, the Debian/Ubuntu arrangement is made even more confusing for
there being three competing "build systems" for Python. There are the
traditional python-central and python-support systems, which most packages
these days use. python-support is probably more popular than python-central
On Nov 22, 2010, at 01:55 AM, Karel Antonio Verdecia Ortiz wrote:
>I'm using stdb to generate .deb packages for ubuntu but I need this packages
>to contain only the compiled modules (.pyc) and not the source modules
>(.py). ¿What parameters have I to use to get only the .pyc files?
Including only
On Nov 18, 2010, at 05:23 PM, Manlio Perillo wrote:
>I usually build Python packages by myself (and often I use virtualenv),
FWIW, virtualenv on Debian has a --setuptools option (and
$VIRTUALENV_USE_SETUPTOOLS environment variable) to force the virtual
environment to use setuptools instead of the
On Oct 30, 2010, at 04:59 PM, Marius Gedminas wrote:
>Why is it a build-dep, anyway? Python's documentation sources are now
>ReStructuredText, not LaTeX -- since 2.6, I think. I don't believe
>there are PDFs shipped in python2.x-doc packages. Is it an obsolete
>build dependency from earlier tim
On Oct 28, 2010, at 02:02 PM, Tres Seaver wrote:
>I like the idea in general, but worry that some conflicts may not be
>resolvable. For instance, I don't know what goal drives system
>packagers to specify UCS4 over the default UCS2, but I won't ever be
>happy using a Python built that way for lon
On Oct 28, 2010, at 12:08 PM, Jim Fulton wrote:
>BTW, I really don't care about certain types of innovation (e.g. file
>locations, wide unicode) as long as I as a developer don't feel them.
>It occurs to me that it would be useful if there was a definition of a
>standard Python that provided a bas
On Oct 08, 2010, at 11:37 PM, P.J. Eby wrote:
>At this point, I'm a bit stumped, as I don't know enough about how tarballs
>are supposed to work internally; should I just whip up a patch for the
>situation where the path has no slashes in it (the logilab case), or do I
>need to do something more s
I just got a new report of a buildout problem with Mailman 3.0a6.
https://bugs.edge.launchpad.net/mailman/+bug/656946
The first part of the problem (corrupt eggs) was easily fixed. It was caused
by a faulty MANIFEST.in that let eggs/ and parts/ leak into the tarball.
However, even with that fixe
On Oct 05, 2010, at 07:04 PM, P.J. Eby wrote:
>At 04:31 PM 10/5/2010 -0400, Barry Warsaw wrote:
>>1) Why does setuptools write a stub loader for the .so in the first place?
>>Why not just let the import of the shared library happen
>> directly using the
>>
I'm working on some patches that allow for multiple builds of Python with
different options to coexist. This is an extension to PEP 3149 and has been
discussed recently in python-dev:
http://mail.python.org/pipermail/python-dev/2010-October/104382.html
This has led me into the twisty maze of set
On Sep 27, 2010, at 09:55 AM, Tarek Ziadé wrote:
>>> However, upload_docs
>>> never quite works out of the box for me anyway. First, it insists
>>> on an index.html file, which my Sphinx builds never seem to write,
>>> so I always have to add a symlink.
>
>Barry, do you mean that you have all fil
On Sep 25, 2010, at 09:41 PM, anatoly techtonik wrote:
>On Tue, Sep 21, 2010 at 5:34 PM, Barry Warsaw wrote:
>>
>> Yes it should definitely use doc/ if docs/ is missing.
>
>Attached patch. Review in context at
>http://codereview.appspot.com/2269042
I commented.
On Sep 21, 2010, at 05:20 PM, anatoly techtonik wrote:
>On Tue, Sep 21, 2010 at 2:57 PM, Barry Warsaw wrote:
>>
>>>I see that distutils2 promotes storing documentation in docs/
>>>directory while Python sources use Doc/
>>>I'd like to see this c
On Sep 21, 2010, at 01:35 PM, anatoly techtonik wrote:
>I see that distutils2 promotes storing documentation in docs/
>directory while Python sources use Doc/
>I'd like to see this changed before distutils2 is released beta.
What does "promotes" mean? That only docs/ can be used?
>In my project
On Aug 30, 2010, at 10:08 AM, Gary Poster wrote:
>> So my question is: would it make sense to be able to ask
>> zope.testrunner where it's running from, so that I don't have to
>> hard code cwd? Better still would be a function in z.t that I could
>> call that would get me back to root directory.
I'm just back from a mini-vacation. Before I left, I upgrade the Mailman 3
branch to use buildout 1.5, but I experienced a build failure [1] and a bunch
of test failures. Gary fixed all the build problems (thanks!) and I think
released a new zope.testrunner package that got my branch back into wo
On Aug 20, 2010, at 11:22 AM, Gary Poster wrote:
>I intend to release zc.buildout 1.5.0 Monday, August 23. I will merge
>the code from from
>svn+ssh://svn.zope.org/repos/main/zc.buildout/branches/gary-betafix
>into trunk.
Cool. Once you do the merge (or maybe before), what's the best way to t
On Jul 28, 2010, at 04:37 PM, Tres Seaver wrote:
>By never, ever, ever distributing binary eggs, especially for Linux.
>An sdist is nearly always consumable there, with the exception of
>deliberately damaged (no tools) lockdown environments: in such
>environments, the dungeonmaster knows exactly
On Jul 27, 2010, at 11:58 AM, P.J. Eby wrote:
>To be clear, I wasn't asking for it to. I was just saying that egg
>platform strings could adopt the d/m/u flags convention, but it wasn't
>in itself sufficient for getting the egg platform string mess sorted
>out on non-Windows/non-OSX platforms.
G
On Jul 27, 2010, at 01:43 PM, David Cournapeau wrote:
>> I wonder if any distutils experts would care to comment on PEP 3149,
>> and its applicability to this problem?
>>
>> http://www.python.org/dev/peps/pep-3149/
>>
>> Is there any way this PEP can help? Do you have any comments that I
>> shoul
On Jul 26, 2010, at 09:26 PM, P.J. Eby wrote:
>At 02:17 PM 7/26/2010 -0400, Barry Warsaw wrote:
>>I wonder if any distutils experts would care to comment on PEP 3149,
>>and its applicability to this problem?
>>
>>http://www.python.org/dev/peps/pep-3149/
>>
>
On Jul 26, 2010, at 06:04 PM, Chris Withers wrote:
>In addition to the UCS2/4 problems already described by MAL and which
>I've bumped into myself, I now have a problem with binary linux eggs
>where the GCC version doesn't match that of the system the egg is
>being installed on.
>
>Current egg met
On Jul 08, 2010, at 10:45 AM, Fred Drake wrote:
>On Thu, Jul 8, 2010 at 10:33 AM, Adam GROSZER
>wrote:
>> Right now I even cannot get the buildout trunk bin/buildout'ed on
>> ubuntu. Does it work for you?
>
>It builds for me (Python 2.6 w/ distribute; haven't tried with
>setuptools), but the test
On Jul 02, 2010, at 12:53 AM, David Cournapeau wrote:
>On Fri, Jul 2, 2010 at 12:23 AM, Barry Warsaw wrote:
>> On Jul 01, 2010, at 04:12 PM, David Cournapeau wrote:
>>
>>>Hm, that's a bit different from my understanding, but that's a bit
>>>irrespon
On Jul 01, 2010, at 04:12 PM, David Cournapeau wrote:
>Hm, that's a bit different from my understanding, but that's a bit
>irresponsible of Ubuntu to provide distribute if it does not get at
>least the bug fixes which go into setuptools. Maybe there is a
>miscommunication here, dunno. I thought th
On Jul 01, 2010, at 11:10 AM, David Cournapeau wrote:
>Ubuntu Lucid uses distribute instead of setuptools, and I cannot
>manage to use setuptools with virtualenv because of this. I upgraded
>to the last version of virtualenv, which claims to install setuptools
>by default, but I still get distribu
On Jun 18, 2010, at 06:01 PM, Andrew Straw wrote:
>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 PP
On Jun 17, 2010, at 12:56 PM, Ian Bicking wrote:
>* Kind of relatedly, make long descriptions wrap in some fashion. Right now
>if you have a plain-text long_description for your project without newlines
>it just gets really wide. I think that'd be fixable with just CSS.
How about supporting reS
On Jun 16, 2010, at 11:14 PM, Simon de Vlieger wrote:
>the recent activity on this mailinglist has kickstarted my
>contributing sense. As long as the mirroring debate is still ongoing I
>will focus my efforts somewhere else. Namely: the HTML/Javascript/CSS.
Hi Simon, nice to see the Cheesesho
Hi Andrew,
I just wanted to follow up on stdeb and the debianize command you added.
First of all, thanks! I've just pulled your git head and tried this out in a
virtualenv, and it works exactly the way I'd hoped. Combined with some of the
other things I'm working out[1] I think this is the way I
On Jun 04, 2010, at 01:07 PM, Ian Bicking wrote:
>On Thu, Jun 3, 2010 at 8:38 AM, Barry Warsaw wrote:
>
>> >So at the end, the end user would chose an installer that is
>> >compatible with these archive, and know how to install them. In other
>> >words, have e
101 - 200 of 284 matches
Mail list logo
