> Could you please explain what the problem is you're complaining about
> instead of assuming everyone knows the details by heart? The only
> reference I saw to 'i386' in PEP 345 is in the section about Environment
> markers and that only refers to the CPU architecture in a test for CPU
> architect
> Chris wrote:
>>> On Sat, Jan 23, 2010 at 7:11 PM, P.J. Eby
>>> wrote:
>>> Notice that other changes are coming up once
>>> the series of PEP we worked on are accepted (which should be before
>>> Pycon - at least for 345 and 386)
>>
>> ok - so are you going to sort out the confusing (i386 == mac)
Hi Tarek,
> For metadata fields like "version", one option I am working on in
> Distutils itself is to have a complementary section in the static
> setup.cfg file, where you can set some fields:
>
> [setup]
> name=foo
> version=1.9.8
Interesting.
Well it was discussed on the mailing list e
Hi Srid,
> I originally posted this in Stackoverflow:
> http://stackoverflow.com/questions/2150887
>
> Here's my buildout.cfg:
>
> ..
> [pyrtm]
> recipe = mercurialrecipe
> repository = http://bitbucket.org/srid/pyrtm
>
> ...
>
> Assume that `pyrtm' has a release on PyPI, but
> On Sat, Jan 23, 2010 at 7:11 PM, P.J. Eby wrote:
> Notice that other changes are coming up once
> the series of PEP we worked on are accepted (which should be before
> Pycon - at least for 345 and 386)
ok - so are you going to sort out the confusing (i386 == mac)
and (x86 == pc) or (i586 == pc)
> Nate wrote:
> I'd hate to see this only end up in 3. We'll probably be supporting 2.x
> for a long time.
>
> Are we any closer to a plan? =) I just found another: (g)libc version.
Well everyday we get closer to seeing the roadmap..
I can give an official answer on that. See:
http://us.pycon
On Thu, 14 Jan 2010 10:36:46 +0100, "M.-A. Lemburg" wrote:
>>> Instead, the version string should include the details of
>>> all included builds, ie. 'x86', 'x64', 'ppc', 'ppc64'.
>> Hashing out the details on what combinations of architectures are valid
>> during installation will be fu
Nate wrote:
> It's not even crucial to me that these be fixed, but before I continue
> to hack up the platform string, I wanted to ask the SIG to address these
> issues and hopefully decide on a standard. That way, I can at least
> implement patches in my app that will be compatible with whatever
> Ben writes:
> However, you're now talking about changing the package format, and not
> the terminology of what we already have. So I'm dropping this
> sub-thread.
ok - up to you. Don't talk about:
http://www.python.org/dev/peps/pep-0376/
David
Hi Tarek,
i386 wrote:
>> setuptools uses distutils.util.get_platform() to decide whether an egg
>> found .. Unfortunately, get_platform() .. compatibility.
>
> I think that this has to be discussed at Distutils/stdlib level.
> Notice that I am currently in the
> process of moving get_platform()
> Hi,
>
> I'm involved with a software project that makes extensive use of third
> party modules with C extensions...
>
> setuptools uses distutils.util.get_platform() to ...
> ..
> ..
> It's not even crucial to me that these be fixed, but before I continue
> to hack up the platform string, I wante
Ben Finney writes:
>> Eliminate : CheesyComestible-1.2.3.zip CheesyComestible-1.2.3.exe
>> CheesyComestible-1.2.3.tar.gz CheesyComestible-1.2.3.bz2
>>
>> Unneccessary and confusing.
>
> How are they unnecessary? There needs to be, at least, a difference
> between the source package and the binary p
Rafeal wrote:
> Windows (NT) used to run also on IA-32, MIPS and PowerPC processors too,
> and Windows (CE) also runs on other CPU FAMILIES other than i386 (ARM,
> MIPS, Hitachi SuperH).
>
> So, no, i386 is just a widely used name to call the subset of the x86
> family that runs on 32bit (vs. the
Martin,
> py> import platform
> py> platform.machine()
> 'i686'
>
> 'i686' maps very well to a real machine on the market, namely to the
> machine on which I'm typing this right now.
Ok.
When I run the same thing:
>import platform
>platform.machine()
>'x86'
So what is being proposed isn
> On Mon, Jan 11, 2010 at 9:19 AM, Barry Warsaw wrote:
> Do you mean, change the general name of these packaged up things from
> "distributions" to "eggs"?
What I mean is that the egg concept abstracts all the packaging
details from the user extremely well.
If a user gets told that all python p
Ned,
> It states in PEP 345 that "the OS and CPU for which the binary
> distribution was compiled" is described in the Supported-Platform field.
Yeah.. it does...
But the CPU in common use today is the 80586.
Renamed for marketing reasons to be the Pentium(tm)
So it is not technically correct
Ned Deily wrote:
> It states in PEP 345 that "the OS and CPU for which the binary
> distribution was compiled" is described in the Supported-Platform field.
> It also says that the semantic of that field are not specified by this
> PEP.
Well it should be made clear where those semantics are to
> In article
>> ..
>> Obviously, some macs have intel processors and some don't. How would a
>> developer reasonably be expected to know which are which? and what
>> difference does it make?
>> ..
>
> In practice, this is seldom an issue on OS X as Pythons supplied by
> python.org and Apple are su
Hi Martin,
>From PEP-345,
> Requires-Dist: foo (1,!=1.3); platform.machine == 'i386'
I'd like to point to the following quote from http://www.apple.com/intel/
"Now every new Mac ships with an Intel processor. Experience delightful
responsiveness from the smallest Mac mini to the most beefed-up
Hi Glyph,
> It sure would be nice if we could use a made-up word like "eggs" to refer
> to these things. Too bad that's taken too :-\.
Yes.
"eggs" is the best name anybody could hope for to describe a package. It
already has general acceptance to a large degree amongst users (despite
it's faul
> On Sun, Jan 10, 2010 at 12:37 AM, Suno Ano wrote:
>> John> I would also add the common use of the term "distribution" to
>> John> that glossary as well.
>>
>> Yes, true that, at http://python.org/download/ we have *distributions*
>> to download.
>>
>> I figure the definition for *Installer* sh
>> > os.machine == 'i386'
>
> It should be platform.machine, not os.machine.
>
>> Haven't seen a '386 for over ten years.. Intel have standardised
>> to calling everything 'Pentium' pretty much since at least 2000.
>
> Irrelevant:
I don't see how it is irrelevent that the constants don't
map to a
Hi John,
> What is expected to be the standard way to do this in the near future?
PEP-345 says:
> Requires-Dist: pywin32 (>1.0); sys.platform == 'win32'
> Obsoletes-Dist: pywin31; sys.platform == 'win32'
> Requires-Dist: foo (1,!=1.3); os.machine == 'i386'
> Requires-Dist: bar; python_versi
se install of the application. Here's the file:
--PKG_INFO---
Name: Print Processor
Platform: Windows
Description: Captures standard printer output
and reformats for GDI printers.
Author: David Lyon
Source_repository: hg:/
> By test coverage results I mean publicly available reports about
> percentage of code covered by tests that were run by testing
> buildbots. See examples:
> http://www.eclipse.org/pde/pde-api-tools/coverage/20091126/eclemma.html
> http://eigenclass.org/static/rcov-sample-report/
> http://web.arc
> On Mon, Jan 4, 2010 at 2:53 PM, anatoly techtonik
> wrote:
Where can I see test coverage results for setuptools package?
I've got two tracebacks in last week after upgrading and that seems to
be too much.
I'd like to see if there are any tests for failing piece to see why
>
On Wed, 30 Dec 2009 19:48:34 +0100, Sebastien Douche
wrote:
> Glad to see someone is interested by a PyPI mirror, I have one here
> and it's a pity.
How did you make it?
> Note: I'm very happy when I see a distribution with:
> - a description
> - a summary (with examples if necessary)
> - a cha
> On Wed, Dec 30, 2009 at 19:48, Sebastien Douche wrote:
>>> Is there significant interest in doing this?
>>
>> YES! ;)
>>
>> In that case, what answer
>>> options should we have?
>>
>> Always upload a version to PyPI, the only way to have a reliable,
>
> The question was if there was interest in
Hi Tarek,
There's one final field that I think that we need and that's
to be able for a software releaser to specify a code-repository
feed source.
It's different than a download url, which may point to
a software 'release'.
The code repository is a changing feed source for software
updates and
> On Sun, Dec 27, 2009 at 17:50, sstein...@gmail.com
> wrote:
>> The tarred download would be really handy for this utility as, if
>> there's no .pkl of the data, or the user requests it, I pull fresh
>> copy.
>
> Right... Anyone want to host such a tarred download? :-)
> I pretty much got the co
> sstein...@gmail.com wrote:
> Hmm ... I think you meant "bikeshedding" (energetic discussion of
> meaningless details) -- "woodshedding" *is* an actual slang term, but
> one that originated among musicians, meaning "to practice one's skills
> alone" (i.e., to go off to a woodshed where no one can
Hi Srid,
On Wed, 23 Dec 2009 14:28:10 -0800, Sridhar Ratnakumar
wrote:
> .. what I was referring to is enabling the mindset: a simple
> *self-contained* (i.e., without having to use an API to get metadata)
> directory structure that can simply be mirrored by using existing tools
> like rsync
On Wed, 23 Dec 2009 10:08:24 +0100, Lennart Regebro
wrote:
>> There is no .tar.gz, .zip, .bz2, .exe, .msi or .egg concept of
>> packages in perl. And having to pick one.. that may or may not
>> be right for your configuration.
>
> So your usecase, that a Windows user refuses to install anything e
On Tue, 22 Dec 2009 19:04:00 +0100, Lennart Regebro
wrote:
> Isn't this turning into the usual "distutils sucks and
> should be rewritten but I can't explain why and how" rant?
Len,
I just want to revisit this, to hopefully close it.
Those words are entirely yours. Not those who are able
to e
On Wed, 23 Dec 2009 02:58:10 +0100, "Martin v. Löwis"
wrote:
>> However, under Windows 7 Enterprise, with a high security policy. It's
>> totally impossible now to install the same package, even if python has
>> been installed by the system administrator. It won't let you run .exe
>> files.
>
>
On Wed, 23 Dec 2009 01:01:11 +0100, Lennart Regebro
wrote:
> OK, so in the Perl community there is apparently a lot of confusion on
> what CPAN is.
CPAN is plain and simple. There is no confusion, because there is
just one 'brand-name' for the whole kit and caboodle. "Packaging"
in the perl worl
On Tue, 22 Dec 2009 19:04:00 +0100, Lennart Regebro
wrote:
> 2009/12/22 David Cournapeau :
>>
>> ..
>>
>> The devil is really in the details for packaging, which is why
>> explicit is a very desirable feature. Someone noticed earlier that
>> distutils was the exact contrary of the python zen on s
On Tue, 22 Dec 2009 19:48:38 +0100, "Martin v. Löwis"
wrote:
>> ..
>
> There is most certainly a reason. The binary distribution may be lacking
> pieces of source code that would be needed to build another (different)
> binary distribution.
Actually, I have a question about that. I'll just ask h
Just use buildout...
On Tue, 22 Dec 2009 10:24:07 +0900, David Cournapeau
wrote:
> Hi,
>
> I wonder if there is any interest in the current distribute effort to
> specify some low-level commonalities outside the distutils code for
> interoperation. In particular, I had two things in mind:
> 1
On Tue, 22 Dec 2009 07:48:55 +0900, David Cournapeau
wrote:
> (cpan) ... is not much a
> feature problem as much as a fundamental implementation and "state of
> mind".
Yes. Their state of mind is make it simple and make it work across
the board for everything for everyone.
> Reliable packaging
Hi Steffen,
On Sun, 20 Dec 2009 15:21:04 + (UTC), Steffen Mueller
wrote:
> It'll be no secret to anyone reading this that there has been a lot of
> discussion recently about a CPAN equivalent for Python, sparked by
> Guido's "People want CPAN" post to the python-distutils-devel list.
Yes Gu
On Tue, 15 Dec 2009 12:58:16 +0530, David Cournapeau
wrote:
> Hi,
>
> I am working on a new packaging solution, and I want to convert
> existing setup.py.
Can I join in ? Is it a public project ?
___
Distutils-SIG maillist - Distutils-SIG@python.o
On Mon, 30 Nov 2009 20:39:32 +0100, Tarek Ziadé
wrote:
> The other big difference is that if you happen to have another problem
> with it in the future, you can count on an actively
> maintained, community-driven project. (IOW not locked by a single
> maintainer that has been AWOL for most of
> t
On Wed, 18 Nov 2009 14:59:21 -0500, Pavol Juhas
wrote:
> Hello,
>
> I searched and read the recent discussions on the distutils-sig
> list and I hope someone can help me with the following problem.
>
> Is there a way to recover the prefix value inside pkgfoo/setup.py,
> when it is installed as
>
On Tue, 17 Nov 2009 08:20:23 -0800, Kevin Teague wrote:
> (although this idea probably came from PyPI's default behaviour, is
> there a way to list all distributions for a project on PyPI?
Yeah of course, see:
http://wiki.python.org/moin/PyPiXmlRpc
David
__
On Fri, 13 Nov 2009 15:25:38 -0500, Tres Seaver
wrote:
* configuration etc
* shared data usr/share/foo/
* readmeusr/share/foo/READMEREADME, TODO, ...
could
be automatically
Hi Greg,
On Thu, 12 Nov 2009 10:02:18 +1300, Greg Ewing
wrote:
> What we need right now, I think, is some discussion
> about a new API, unconstrained by any considerations of
> backwards compatibility
A new API isn't so hard, but like anything it takes time
and effort to do.
Already this
Original Message
Subject: installing lxml ?
Date: Wed, 11 Nov 2009 04:49:48 -0800 (PST)
From: 7stud
To: python-l...@python.org
I'm trying to install lxml, but I can't figure out the installation
instructions. Here:
http://codespeak.net/lxml/installation.html
it says:
1) Get
On Wed, 11 Nov 2009 19:14:42 +1300, Greg Ewing
wrote:
> Also, it seems to me that in this case, the basic
> architecture of distutils is already so full of
> mistakes that there just isn't an incremental way
> of getting to a better place, especially given the
> requirement of not breaking any ex
On Mon, 09 Nov 2009 17:25:45 -0600, Robert Kern
wrote:
> We're talking about release numbers for the binary package made by
> third parties like ActiveState or Enthought. As we fix bugs in our
> build process for each package, we may need to release multiple
> binary packages for each main
Tha
On Mon, 09 Nov 2009 17:01:53 -0600, Robert Kern
wrote:
>> Ok, well they're part of http://www.python.org/dev/peps/pep-0345/
>>
>> I'll revise my statement back to saying that doing it according
>> to PEP-345 makes the most sense imho.
>
> Where? I don't see it.
Right at the top, 3rd field, after
On Mon, 09 Nov 2009 16:39:40 -0600, Robert Kern
wrote:
>> But release numbers are already stored in the PKG_INFO metadata
>> file. Why store it somewhere else?
>
> No, they're not.
>
> http://www.python.org/dev/peps/pep-0241/
Ok, well they're part of http://www.python.org/dev/peps/pep-0345/
I'
On Mon, 09 Nov 2009 13:45:29 -0800, "Sridhar Ratnakumar"
wrote:
> Same with PyPM. Which is why release numbers need to be stored elsewhere.
> Given the current design/proposals - what makes sense to me now is to
> store it in .egg-info/PyPM.txt.
But release numbers are already stored in the P
On Mon, 09 Nov 2009 13:32:55 -0800, "Sridhar Ratnakumar"
wrote:
> I suggest that we check for valid metadata on the uploaded sdists at the
> least. If you visit http://pypm.activestate.com/ - most failed packages
> are due to the fact the sdist uploaded by the author misses certain files
>
On Sun, 8 Nov 2009 23:28:42 -0600, Ian Bicking wrote:
> In the tools I've written, I generally give the traceback if the
> verbosity is turned up, and in a case like this (an unexpected
> exception -- for distutils that's any exception except a few that
> distutils defines) I include "use -v for
On Sun, 8 Nov 2009 19:19:44 +, Floris Bruynooghe
wrote:
> .. improve the PEP 386
> reference implementation for example (I pick that one as I know most
> about it from all the PEP proposals currently).
I'm +1 on PEP-386. It makes sense to me.
> This is a PEP that should maybe be finished fi
On Sat, 7 Nov 2009 16:08:46 +0100, Tarek Ziadé
wrote:
> Gosh. I am not your boss, and I am not telling you what to do.
otoh you're the boss of distutils. So you can direct people to
work on certain things to help you along. That would have kept
me much quieter with work.
> I am just telling yo
Hi Tarek,
On Sat, 7 Nov 2009 12:12:44 +0100, Tarek Ziadé
wrote:
> You don't understand at all what is going on I think.
I guess so.
> .. it means that we can take
> more help from more people (and that includes you of course).
I really do accept that.
What's hard for me to understand exactl
On Sat, 7 Nov 2009 06:53:17 -0600, Brad Allen
wrote:
> During that conversation Walker mentioned that he thought that Java's
> Maven packaging system had been really successful with the idea of
> having a metadata file stored outside each package. That made it
> easier for the metadata format to e
Hi Jeff,
On Sat, 07 Nov 2009 06:04:15 -0600, Jeff Rush wrote:
> I keep reading and I keep hearing you and others saying this, but as
> someone who has never used CPAN, I'm not seeing the large number of
> specific implementable tasks that CPAN clearly has and PyPI clearly does
> not.
ok. Fair
Hi David,
I have to agree with you on every point.
On Sat, 07 Nov 2009 16:49:12 +0900, David Cournapeau
wrote:
> Contrary to other people, I don't think a successor to distutils is that
> hard to develop, especially since good designs in other languages
> already exist. It would take time, esp
> On Fri, Oct 30, 2009 at 6:24 PM, Chris Withers
> wrote:
>> I think "python setup.py install" is so idiomatic that it seems silly to
>> break it for the sake of two lines of python.
Ok. Well, I've been experimenting with "python -m setup install" and
I'm sure that I can get it to do the right th
On Mon, 02 Nov 2009 19:14:56 +0100, Georg Brandl wrote:
> The beauty of the "python -m setup" approach is that it will execute the
> setup.py in the current directory if present, or a stdlib-supplied one
> if not.
Ok - I copied the file to \pythonX.Y\lib and ran 'python -m setup' and
got an inst
On Sun, 1 Nov 2009 11:26:43 +, Floris Bruynooghe
>> Has anyone already suggested something like "python -m setup install"?
>> It would be rather similar and explicit, too.
Actually, I never came across that command line option and had no idea
that it even existed. But this is normal, because I
On Sun, 01 Nov 2009 09:31:46 +0100, Georg Brandl wrote:
>> I think "python setup.py install" is so idiomatic that it seems silly to
>> break it for the sake of two lines of python. There's also an element of
>> "explicit is better than implicit" in the feel of actually running
>> setup.py...
>
Antonio,
I completely get what you're saying.
Anyway, we shouldn't be considering dropping bdist_wininst installers
for windows unless we actually have something viable to replace them
with.
As much as I don't think they are the ideal solution, I'd hate to
think about having to to package ins
On Wed, 28 Oct 2009 14:23:58 +, Chris Withers
wrote:
> ...would get everyone from the static metadata file, while any keyword
> parameters to setup would override the appropriate setting from the
> static metadata file...
Hi Chris, David, Fred, Floris, Tarek, PJE, ...
Everybody has been so
On Wed, 28 Oct 2009 12:26:19 +0900, David Cournapeau
> You can't ban setup.py: although ...
haha - of course.
ban setup.py as in ban alcohol or ban using a mobile phone when driving.
> With toydist, there would be a new build system not based on distutils,
> and which would indeed works like thi
On Tue, 27 Oct 2009 16:52:36 +, Chris Withers
wrote:
> from distutils.core import setup,parse_static
> setup(**parse_static('setup.cfg').to_dict())
>
> ...and of course, because setup.cfg is the default name, we just end up
> with:
>
> from distutils.core import setup
> setup()
Nice..
But
On Tue, 27 Oct 2009 20:06:11 -0400, Glyph Lefkowitz
> If you're concerned about security and distutils, there is a _lot_ of
> work to do. There is no particular additional danger in executing
> a .exe rather than a setup.py.
Come to think of it.. you're totally right..
:-(
David
On Tue, 27 Oct 2009 18:51:07 -0500, Robert Kern
wrote:
> easy_install does not execute the executable. bdist_wininst installers
are
> zip
> files concatenated with an executable header. easy_install just unzips
the
> file
> as if it were a zipped egg and ignores the executable part.
Ok - well
On Tue, 27 Oct 2009 20:51:10 +0100, Tarek Ziadé
wrote:
> $ easy_install your_bdist_wininst_dist.exe
>
> will install it and process the dependencies from the install_requires
> option.
>
> And pip should be compatible soon too. That makes this format a
> perfect binary format for win32.
I'm no
On Wed, 21 Oct 2009 14:28:06 +0200, Piotr Ozarowski
wrote:
> Sure, one could just:
>
> | try:
> | import setuptools
> | except ImportError:
> | import ez_setup
> | ez_setup.use_setuptools()
>
> and thus use installed version if it's available (replace
> ez_setup/setuptools with what
On Wed, 21 Oct 2009 10:48:00 +0200, Tarek Ziadé
wrote:
> So do you have a use case where a Python distribution needs to use "64
> bit (the machine)"
> in order to provide a different requires ?
I wouldn't be too worried about this '64' bit issue.
Hypothetically, C library extensions can/could b
On Wed, 21 Oct 2009 11:24:12 +0200, Piotr Ozarowski
wrote:
> Hi list,
>
> I'm a Debian developer who is interested in changes you want to
> introduce so I'll add my 2 cents from time to time if you don't mind.
Hello. Yes, a virtual 2c is valuable. Certainly the best offer I've had
all day..
> a
On Wed, 21 Oct 2009 09:02:40 +0100, Chris Withers
wrote:
>> If the file is 100kb long, I don't think a user would care.
>
> I'm "a user" in this case, and I care... The maintenance burden a file
> like the setup.py you're proposing places on me as a package author in
> making sure the package
On Wed, 21 Oct 2009 08:24:06 +0100, Chris Withers
wrote:
> David Lyon wrote:
>> Well I put my code up here:
>>
>> https://bitbucket.org/djlyon/original-setup.py-with-metadata/
>
> The thing is, there's just no need for all this code to be in setup.py.
>
>
On Wed, 21 Oct 2009 08:29:02 +0100, Chris Withers
wrote:
> David Lyon wrote:
>> So I will build an option in to check on the net for an updated
>> version before starting.
>
> That won't fly.
but it will most definitely work...
and it will be backwards co
Hi Chris,
Well I put my code up here:
https://bitbucket.org/djlyon/original-setup.py-with-metadata/
Plenty on the todo list..
David
On Tue, 20 Oct 2009 13:53:31 +0100, Chris Withers
wrote:
> David Lyon wrote:
>> What we actually need, and I am building, is a setup.py script
>>
On Tue, 20 Oct 2009 13:28:56 +0100, Chris Withers
wrote:
> Yes, and yet everytime I ask for the ability specify long description as
> a file path relative to the pacakge, I get shouted at ;-)
[setup]
name = artistflair
version = 1.2
description_file = flairdescript.rst
A soft voice is calling y
On Tue, 20 Oct 2009 13:53:31 +0100, Chris Withers
wrote:
> Be very aware of the problems of proliferating boilerplate code
> (buildout has already suffered this):
>
> - old versions will have to work forever
>
> - bug fixes are *very* hard to do
Well, you're probably right.
So I will build an
On Tue, 20 Oct 2009 09:36:08 -0400, Fred Drake wrote:
> If we adopt such a micro-language (I'm reserving judgment until I've
> had more time to read the relevant PEPs carefully), I'd rather see the
> names match what's in the Python runtime more closely, probably only
> avoiding the call syntax.
On Tue, 20 Oct 2009 12:41:52 +0900, David Cournapeau
wrote:
>>> 'if desktop in "gnome|windows"' etc
>
> Agreed, this is too fragile and complicated.
I don't understand which part is fragile.
Detecting if gnome or windows exists? or implementing this via Tareks
proposal (sort of shown as best a
On Mon, 19 Oct 2009 07:44:56 -0400, Steve Steiner wrote:
> I am not looking to hand-fix this, that would be pointless. I want an
> automated build script that will fire up a brand new Ubuntu cloud
> server, set up the entire environment, install the buildbot and run.
Can I help?
It's actua
On Mon, 19 Oct 2009 13:46:11 +0200, Tarek Ziadé
wrote:
> From the stdlib PoV, exposing new variables like "gnome" isn't
> appropriate, because
> we don't want to keep track of all desktop systems in the stdlib.
> That's impossible.
Well, the list isn't infinite. And under Linux there are only
two
On Mon, 19 Oct 2009 10:18:57 +0100, Floris Bruynooghe
wrote:
> All this seems like a bad idea to me. Thinking from a GNU/Linux
> distro point of view now you'd need to add a build-depends to e.g. GDM
> *and* KDM only to get the correct .desktop file or something like
> that. And even worse, as p
On Tue, 13 Oct 2009 17:55:36 +0900, David Cournapeau
>> [datafiles]
>> files = artisticdb.dbf
>> artisticdb.mdx
>> authors.dbf
>> authors.mdx
>> directory = db
>
> How would you handle the case where you have several data directories ?
[datafiles]
directories = data/us_data
data/
On Sat, 17 Oct 2009 18:19:44 +0200, Tarek Ziadé
wrote:
> If you can find a way to express conditions based on os.environ,
> maybe os.environ could be added to the variables that are used
> when checking the markers on a given platform.
I'm not sure that you should try to do that. It would make th
On Sat, 17 Oct 2009 01:53:48 +0200, Tarek Ziadé
wrote:
> So far.. so good. It's basically what we proposed earlier in PEP 390, but
> for
> the distribution, the desktop (kde, etc)...
..
> That would require a new
> stdlib module that would be very hard to implement and maintain since
> it's a fa
On Sat, 17 Oct 2009 01:15:25 +0200, Tarek Ziadé
wrote:
> On Sat, Oct 17, 2009 at 12:39 AM, David Lyon
> wrote:
>> Requires: (linux-suse-kde-64) foo
>
> How this expression would be verified on the target system ?
I'm working on coding it. Basically the strings are a
On Fri, 16 Oct 2009 15:54:29 +0200, Tarek Ziadé
wrote:
> But what really matters at the end is to provide a new Metadata format
> where these marker are present, so any consumer
> can play with them (and Distutils provide an API to play with them :
> the DistributionMetadata class)
I'm fine with
On Fri, 16 Oct 2009 12:22:20 +0900, David Cournapeau wrote:
> The problem is a bit more complicated, because it cannot be handled in
> one single section.
I really appreciate you sharing this challenge with me.
I'm really convinced that I can "tweak" something to make it work. And
now is a reall
I really love this stuff..
It's better than soap opera..
We have jerks, interjectors, behind the scenes plots, secret messages,
moles and flashbacks..
I'm staying tuned in and hope tomorow's episode will be just as thrilling
as todays..
> At 02:38 PM 10/15/2009 -0400, sstein...@gmail.com wrote
On Thu, 15 Oct 2009 14:48:00 +0900, David Cournapeau
wrote:
> Let's take a common case: using cython/pyrex to accelerate some code,
> but you still want people to be able to use your package without a C
> compiler (bzr, cython are examples of such packages).
I believe that's possible through the
On Thu, 15 Oct 2009 13:39:32 +0900, David Cournapeau
wrote:
> I understand this, but when you a lot of conditioning, "flattening" the
> conditions is not really readable. If you have say 10 variables instead
> of 2 to condition on, the sections would be several lines.
I'm only allowing up to fou
On Thu, 15 Oct 2009 12:16:48 +0900, David Cournapeau
wrote:
> I think nested conditions for configurations is a must-have. Once you
> have more than 2-3 variables, doing it like PEP 390 is not really
> manageable. Particularly for C extensions, having many configurations is
> quite common in my e
On Thu, 15 Oct 2009 10:59:48 +0900, David Cournapeau
wrote:
> Saying that a packaging tool is about copying files is not very useful -
> you could say that programming is just moving bytes around and you would
> be right as well :)
Well it is about moving bytes around..
That *is* just how I see
On Wed, 14 Oct 2009 18:52:57 -0700, Kevin Teague wrote:
>> ConfigParser was first documented in Python 1.5.2, released 30 April
>> 1999.
>>
>> Some of us remember the releases that came before, but (thankfully)
>> we're outnumbered. :-)
>
> 1.5.1 was the first Python that I used, seems like I
On Wed, 14 Oct 2009 11:21:40 +0200, Tarek Ziadé
wrote:
> My suggestion is that once you have a revised PEP that includes some
> proof of concept
> code with less overlapping with PEP 390 (they are different proposals
> obviously),
> you post it here for a round of feedback, then I'll push it in th
Hi Eric..
On Wed, 14 Oct 2009 08:46:26 -0400, Eric Smith wrote:
>>> The first one who mentioned the idea was Eric IIRC, then Matthias and
>>> Tres worked on it.
>>
>> Fine. They've been awfully quiet on distutils-sig lately :-)
>
> Not so!
:-)
>> Sure. Well "collect" is a word ..
>
> I'm sur
1 - 100 of 273 matches
Mail list logo
