On 26 Jul 2014, at 08:54, Nick Coghlan wrote:
> On 26 July 2014 15:27, Wichert Akkerman wrote:
>> I suspect that for Linux you mean “system-provided Python”? Looking at
>> https://www.python.org/downloads/release/python-341/ there is no python.org
>> binary installer for Linux. Even if there wa
On 22 Aug, 2012, at 4:52, Daniel Holth wrote:
> I've made what I think is exciting progress on the digital signatures
> design for wheel (updated built/binary packages for Python; intended
> to replace egg). The insight is that we can overload the "extras"
> syntax as a convenient way to mention
On 22 Oct, 2012, at 20:03, anatoly techtonik wrote:
> What do you think about this?
>
> http://bugs.python.org/issue16299
The cost of changing the build directory is high, and has limited upsides at
best. Some of the costs: confusing current users, breaking existing
documentation like books,
On 18 Oct, 2012, at 19:29, Daniel Holth wrote:
> I'd like to submit the Wheel PEPs 425 (filename metadata), 426
> (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has
> been stable since May and we are preparing a patch to support it in
> pip, but we need to earn consensus befor
On 18 Oct, 2012, at 19:29, Daniel Holth wrote:
> I'd like to submit the Wheel PEPs 425 (filename metadata), 426
> (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has
> been stable since May and we are preparing a patch to support it in
> pip, but we need to earn consensus befor
On 24 Oct, 2012, at 14:59, Daniel Holth wrote:
> On Wed, Oct 24, 2012 at 7:04 AM, Ronald Oussoren
> wrote:
>>
>> On 18 Oct, 2012, at 19:29, Daniel Holth wrote:
>>
>>> I'd like to submit the Wheel PEPs 425 (filename metadata), 426
>>> (Metad
On 25 Oct, 2012, at 9:23, anatoly techtonik wrote:
> On Tue, Oct 23, 2012 at 9:28 AM, Ronald Oussoren
> wrote:
>>
>> On 22 Oct, 2012, at 20:03, anatoly techtonik wrote:
>>
>>> What do you think about this?
>>>
>>> http://bugs.python.o
On 24 Oct, 2012, at 14:48, Daniel Holth wrote:
> On Wed, Oct 24, 2012 at 7:28 AM, Ronald Oussoren
> wrote:
>>
>> On 18 Oct, 2012, at 19:29, Daniel Holth wrote:
>>
>>> I'd like to submit the Wheel PEPs 425 (filename metadata), 426
>>> (Metad
On 31 Oct, 2012, at 13:38, Daniel Holth wrote:
> On Wed, Oct 24, 2012 at 7:04 AM, Ronald Oussoren
> wrote:
>>
>> On 18 Oct, 2012, at 19:29, Daniel Holth wrote:
>>
>>> I'd like to submit the Wheel PEPs 425 (filename metadata), 426
>>> (Metad
On 13 Nov, 2012, at 16:00, Daniel Holth wrote:
>
> I want to remove distutils from the standard library.
Why? Distutils may not be perfect, but is usable for basic packages. It could
even be enhanced to support these peps and be even more useable, although
patches for that would run into the
On 13 Nov, 2012, at 17:21, Antoine Pitrou wrote:
> Le Tue, 13 Nov 2012 16:10:30 +0100,
> Ronald Oussoren a écrit :
>>
>> On 13 Nov, 2012, at 16:00, Daniel Holth wrote:
>>>
>>> I want to remove distutils from the standard library.
>>
>> Why?
On 13 Nov, 2012, at 18:32, Martin v. Löwis wrote:
> Am 13.11.12 17:45, schrieb Maciej Fijalkowski:
>> For example distutils is absolutely *untestable* which makes it very
>> far from good enough for me.
>
> I never had issues with testing distutils applications. I use
> "python setup.py sdist",
On 19 Nov, 2012, at 20:26, PJ Eby wrote:
>
>
> Data files should never be installed to package directories. But I'm not
> aware of any good reason why resource files should ever be installed anywhere
> *else*.
To be (too) snarky: because the FHS says so.
Less snarky, Linux distributors tr
On 4 Feb, 2013, at 17:00, a.cava...@cavallinux.eu wrote:
> I agree *completely* with Philippe here.
>
> If a version standard will be enforced what's the point of making it more
> complicated that a sequential number or something along x.y.z? In the end
> that's
> what the version number is.
B
On 4 Feb, 2013, at 20:59, Antonio Cavallo wrote:
> > Because the version number is just more complicated? The details have been
> > ...
>
> Nope, the whole point is it shouldn't. If that has to be enforced why adding
> "marketing alert" to it? Why choosing something complex over something sim
On 12 Feb, 2013, at 8:08, Nick Coghlan wrote:
>
>
> So, to my mind, the next PEP we're missing is actually one for the
> *sdist* format itself, including a definition for how the
> meta-packaging system should invoke the sdist->wheel build step,
> rather than one for the Archiver/Builder config
On 12 Feb, 2013, at 9:33, Nick Coghlan wrote:
> On Tue, Feb 12, 2013 at 6:25 PM, Ronald Oussoren
> wrote:
>>> PEPs 426 and 427 between them should achieve the first objective,
>>> while the other parts of PEP 426 should get us a long way towards
>>> achie
On 12 Feb, 2013, at 14:46, Daniel Holth wrote:
>
>
> I still think it makes more sense to just download distribute and wheel when
> you want to build one, but to each his own... if you need to create packages
> for pypi without being able to install things from it, knock yourself out.
Why th
On 12 Feb, 2013, at 16:55, Daniel Holth wrote:
> On Tue, Feb 12, 2013 at 10:04 AM, Nick Coghlan wrote:
>
> On 13 Feb 2013 00:55, "Ronald Oussoren" wrote:
> >
> >
> > On 12 Feb, 2013, at 14:46, Daniel Holth wrote:
> > >
> > >
&
On 25 Mar, 2013, at 19:16, PJ Eby wrote:
>
>
> Also, as far as detecting the need for setuptools, I think that can be
> done just by noticing whether the PKG-INFO included in an sdist is
> metadata 2.0 or not. If it is, then setuptools should be explicitly
> declared as a build-time dependency
On 26 Mar, 2013, at 12:06, Daniel Holth wrote:
>
> On Mar 26, 2013 5:28 AM, "Ronald Oussoren" wrote:
> >
> >
> > On 25 Mar, 2013, at 19:16, PJ Eby wrote:
> > >
> > >
> > > Also, as far as detecting the need for setuptools, I think
On 26 Mar, 2013, at 13:27, Daniel Holth wrote:
> stall themselves, they can just mention setup-requires and the installer
> grabs the necessary setuptools.
> > >
> > That can only be done for sdists with 2.0 metadata, sdists for older
> > versions don't have a setup-requires in their metadata.
On 26 Mar, 2013, at 16:21, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/26/2013 05:28 AM, Ronald Oussoren wrote:
>>
>> On 25 Mar, 2013, at 19:16, PJ Eby wrote:
>>>
>>>
>>> Also, as far as detecting the nee
On 29 Mar, 2013, at 21:11, Nick Coghlan wrote:
> On Fri, Mar 29, 2013 at 8:43 AM, Daniel Holth wrote:
>> WinZip will ignore anything in the front of the file since the zip
>> directory doesn't reference it. The #! shebang is for Unix, would
>> point to the correct Python, and the +x flag would
On 25 Apr, 2013, at 15:58, Daniel Holth wrote:
> I would prefer to see PEP 390 withdrawn and I think this has been
> suggested before. The metadata is already sourced from different files
> depending on your build system.
I wouldn't mind a PEP 390 update when the 2.0 metadata format is done
th
On 19 May, 2013, at 2:51, Donald Stufft wrote:
>>
>
> Forgot to mention, both of those options are available by clicking on "urls"
> when viewing a package you have permissions on, see:
> http://d.stufft.io/image/2h073q2L3Z29
I get a "Forbidden" error when following the "urls" link in Safari
On 27 May, 2013, at 13:36, Nick Coghlan wrote:
> After preliminary reviews by Donald and Daniel, I have now pushed the
> first complete draft of the JSON-based metadata 2.0 proposal to
> python.org
>
> PEP 426 (metadata 2.0): http://www.python.org/dev/peps/pep-0426/
Could platform_release be a
On 29 May, 2013, at 20:36, holger krekel wrote:
> Hi Nick,
>
> On Mon, May 27, 2013 at 21:36 +1000, Nick Coghlan wrote:
>> After preliminary reviews by Donald and Daniel, I have now pushed the
>> first complete draft of the JSON-based metadata 2.0 proposal to
>> python.org
>>
>> PEP 426 (metad
On 31 May, 2013, at 22:17, Chris Barker - NOAA Federal
wrote:
> HI Folks,
>
> A few of us over on the pythonmac list have been hashing out how best
> to support binary packages on OS-X. The binary wheel option seems very
> promising.
>
> However, there is one Mac-specific issue that does not
On 4 Jun, 2013, at 18:35, Chris Barker - NOAA Federal
wrote:
> On Mon, Jun 3, 2013 at 3:47 PM, Daniel Holth wrote:
>
>> That would make sense. Can you come up with code to detect that a
>> newly compiled extension is universal, and that a Python is?
>
> It looks like distutils.util.get_platf
On 4 Jun, 2013, at 18:27, Chris Barker - NOAA Federal
wrote:
> On Tue, Jun 4, 2013 at 1:23 AM, Ronald Oussoren
> wrote:
>
>> This isn't really a problem, distutils uses labels for the set of supported
>> architectures as the architecture label in binary distribut
On 4 Jun, 2013, at 23:53, Chris Barker - NOAA Federal
wrote:
> On Tue, Jun 4, 2013 at 9:55 AM, Ronald Oussoren
> wrote:
>
>>> $ otool -L python
>>> python (architecture ppc):
>>> /Library/Frameworks/Python.framework/Versions/2.7/Python
>>>
On 21 Jun, 2013, at 14:21, Paul Moore wrote:
> On 21 June 2013 12:35, Nick Coghlan wrote:
> The quick compatibility check is actually part of the wheel file
> naming specification (it's covered by the compatibility tags defined
> in PEP 425).
>
> Yes, I was thinking more of the sdist side - an
On 21 Jun, 2013, at 1:24, Nick Coghlan wrote:
> >
> > 1. Python setup.py sdist and python setup.py dist_info will be changed to
> > generate pymeta.json files. But that will be for Python 3.4 only (there's a
> > big problem if this doesn't make it into 3.4...). Unless there's a
> > distutils
On 10 Jul, 2013, at 11:40, Richard Jones wrote:
> On 10 July 2013 19:08, Vinay Sajip wrote:
>> Richard Jones gmail.com> writes:
>>
>>> pip without virtualenv in python 2 contexts is pretty rare (or at
>>> least *should* be ) so I think I'll retain it in that bootstrap
>>> code.
>>
>> Perhaps
On 13 Jul, 2013, at 7:31, Nick Coghlan wrote:
>
> 3. That means there are two main options available to us that I still
> consider viable alternatives (the installer bundling idea was suggested in
> one of the off list comments I mentioned):
>
> * an explicit bootstrapping script
> * bundli
On 13 Jul, 2013, at 15:35, Brett Cannon wrote:
>
>
>
> On Sat, Jul 13, 2013 at 2:29 AM, Ned Deily wrote:
> In article <55b209b3-9576-4cf0-b58c-2a1e692af...@stufft.io>,
> Donald Stufft wrote:
> > On Jul 13, 2013, at 1:31 AM, Nick Coghlan wrote:
> > > I'm currently leaning towards offering
On 13 Jul, 2013, at 16:39, Vinay Sajip wrote:
>
>
> I smoke-tested the script on vanilla Python 3.3 installations on Windows and
> OS X. On OS X, the pip script was written to the appropriate Frameworks
> folder, but not to /usr/local/bin - I assume it would be simple enough to
> arrange that?
On 16 Jul, 2013, at 13:25, Paul Moore wrote:
>
> On the other hand, I'm missing something, as I don't see how the *current*
> exe wrappers avoid meaning that there need to be separate 32-bit and 64-bit
> versions of pip...
Couldn't you just ship both variants of the exe wrappers in a single
On 16 Jul, 2013, at 15:08, Paul Moore wrote:
> On 16 July 2013 13:42, Ronald Oussoren wrote:
> > On the other hand, I'm missing something, as I don't see how the *current*
> > exe wrappers avoid meaning that there need to be separate 32-bit and 64-bit
> > versi
On 17 Jul, 2013, at 17:46, Daniel Holth wrote:
> On Wed, Jul 17, 2013 at 11:12 AM, Brett Cannon wrote:
>> I'm going to be pushing an update to one of my projects to PyPI this week
>> and so I figured I could use this opportunity to help with patches to the
>> User Guide's packaging tutorial.
>>
On 17 Jul, 2013, at 17:55, Paul Moore wrote:
>
> On 17 July 2013 16:46, Daniel Holth wrote:
> > * Are we saying "use setuptools" for everyone, or still only if you need it
> > (asking since there is a stub about installing setuptools but the simple
> > example doesn't have a direct need for it
On 17 Jul, 2013, at 19:17, Trishank Karthik Kuppusamy
wrote:
>
> To very briefly summarize our status without going into tangential details:
>
> 1. We previously found and reported on this mailing list that if we naively
> assigned a key to every PyPI project, then the metadata would not scal
On 18 Jul, 2013, at 13:48, Oscar Benjamin wrote:
> On 17 July 2013 22:43, Nick Coghlan wrote:
>>
>> On 18 Jul 2013 01:46, "Daniel Holth" wrote:
>>>
>>> On Wed, Jul 17, 2013 at 11:12 AM, Brett Cannon wrote:
I'm going to be pushing an update to one of my projects to PyPI this
week
>
On 29 Jul, 2013, at 22:33, Donald Stufft wrote:
>
> On Jul 29, 2013, at 3:14 PM, Donald Stufft wrote:
>
>>
>> On Jul 29, 2013, at 2:57 PM, zooko wrote:
>>
>>> I'd like to push back on the other risk, that someone might figure out how
>>> to
>>> make MD5 second-pre-images. I don't think th
On 20 Aug, 2013, at 8:15, samuel.feren...@barclays.com wrote:
>> -Original Message-
>> From: Chris Barker - NOAA Federal [mailto:chris.bar...@noaa.gov]
>> Sent: Monday, August 19, 2013 7:13 PM
>> To: Ferencik, Samuel: Markets (PRG)
>> Cc: distutils-sig@python.org
>> Subject: Re: [Distuti
On 20 Aug, 2013, at 18:00, samuel.feren...@barclays.com wrote:
>> -Original Message-
>> From: Chris Barker - NOAA Federal [mailto:chris.bar...@noaa.gov]
>> Sent: Tuesday, August 20, 2013 5:47 PM
>> To: Ferencik, Samuel: Markets (PRG)
>> Cc: distutils-sig@python.org
>> Subject: Re: [Distu
On 23 Aug, 2013, at 0:52, Paul Moore wrote:
> On 22 August 2013 23:08, Chris Barker - NOAA Federal
> wrote:
> I want to give it a shot for OS-X -- no one seems to want to maintian
> bdist_mpkg, and it's time to move forward...
>
> My impression is that the architecture and "fat binary" stuff
On 23 Aug, 2013, at 5:17, Nick Coghlan wrote:
>
> That said, I'm considering the idea of adding a "variant" field to the
> compatibility tags for wheel 1.1, along the lines of what Oscar
> Benjamin suggested earlier. By default, installers would only find
> wheels without a variant defined, but
On 31 Aug, 2013, at 17:56, Nick Coghlan wrote:
>
> This perception is just wrong. Mac OS X is a mess due to clang vs gcc vs
> homebrew vs macports vs Xcode, Windows is a mess due to mingw and cygwin and
> platform SDKs and visual studio (Express or otherwise). Linux distros are
> also ridicu
On 5 Sep, 2013, at 19:32, Daniel Holth wrote:
> On Thu, Sep 5, 2013 at 8:33 AM, Ronald Oussoren
> wrote:
>>
>> On 31 Aug, 2013, at 17:56, Nick Coghlan wrote:
>>
>>>
>>> This perception is just wrong. Mac OS X is a mess due to clang vs gcc vs
>
On 21 Oct, 2013, at 20:52, Donald Stufft wrote:
>
> On Oct 21, 2013, at 1:02 PM, Chris Barker wrote:
>
>> On Fri, Oct 18, 2013 at 6:22 PM, Nick Coghlan wrote:
-- it would be very useful if folks could easily
get binary wheels for OS-X
>>>
>>> We do plan to support it, but the pip
On 19 Oct, 2013, at 3:22, Nick Coghlan wrote:
>
> On 19 Oct 2013 04:59, "Chris Barker" wrote:
> >
> > Someone on another list indicated that pip installing binary wheels
> > from PyPi will ONLY work for Windows.
> >
> > Is that the case? I think it's desperately needed for OS-X as well.
> >
>
On 31 Oct, 2013, at 15:26, Nick Coghlan wrote:
> On 31 October 2013 23:38, Ronald Oussoren wrote:
>>
>> On 21 Oct, 2013, at 20:52, Donald Stufft wrote:
>>
>>>
>>> On Oct 21, 2013, at 1:02 PM, Chris Barker wrote:
>>>
>>>> On Fri
On 31 Oct, 2013, at 17:49, Daniel Holth wrote:
> On Thu, Oct 31, 2013 at 10:26 AM, Nick Coghlan wrote:
>> On 31 October 2013 23:38, Ronald Oussoren wrote:
>>>
>>> On 21 Oct, 2013, at 20:52, Donald Stufft wrote:
>>>
>>>>
>>>> On O
On Oct 31, 2013, at 07:24 PM, Donald Stufft wrote: On Oct 31, 2013, at 1:15 PM, Ronald Oussoren <ronaldousso...@mac.com> wrote: Is it "just" a matter of researching if the various build options on OSX really lead to binaries with the same ABI, or is more work needed? Basically i
Hi,
Is there a way to create a wheel that contains only python code, but can only
be installed on particular platforms?
In particular, I’m looking for a way to create a wheel for py2app that can only
be installed on OSX because py2app cannot “cross-compile” application bundles.
Ronald
__
tform tag doesn’t
allow for wildcards. That is, there is no way to specify “any linux”, only
something like “linux_x86_64” (to borrow a tag from PEP 425).
Ronald
>
> On Thu, Jan 30, 2014 at 1:14 PM, Ronald Oussoren
> wrote:
>> Hi,
>>
>> Is there a way to create a wheel
On 30 Jan 2014, at 19:23, Vinay Sajip wrote:
>
>
> On Thu, 30/1/14, Ronald Oussoren wrote:
>
>> Is there a way to create a wheel that contains only python code, but
>> can only be installed on particular platforms?
>
On 30 Jan 2014, at 19:36, Daniel Holth wrote:
> On Thu, Jan 30, 2014 at 1:29 PM, Ronald Oussoren
> wrote:
>>
>> On 30 Jan 2014, at 19:19, Daniel Holth wrote:
>>
>>> Your best bet currently is to execute the "mv" command to change the
>>>
On 30 Jan 2014, at 17:27, Vinay Sajip wrote:
>
>
> On Thu, 30/1/14, Eric V. Smith wrote:
>
>> The flag really needs to convey 2 meanings:
>> - - There are some C extensions here that can't be loaded
>> unless they live on a real filesystem p
Are there any plans to teach EasyInstall about build time
dependencies? And example of this would be the dependency of PIL on
libjpeg and libtiff.
Ronald
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/
On 9-jun-2005, at 13:14, Phillip J. Eby wrote:
> At 12:36 PM 6/9/2005 -0700, Ronald Oussoren wrote:
>
>> Are there any plans to teach EasyInstall about build time
>> dependencies? And example of this would be the dependency of PIL on
>> libjpeg and libtiff.
>>
>
On 15-sep-2005, at 20:10, Robert Kern wrote:
Kevin Dangoor wrote:
On 9/15/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
As for Mac OS, I have almost no experience with it, so I'm not
sure what
GUI applications there need. Does everything need py2app? If
you have a
wx-based app, would
On 21-sep-2005, at 2:59, Phillip J. Eby wrote:
That leaves OS X, where I gather that convention and policy
dictates that
applications just be runnable without an install step. There you can
bundle all your eggs, and rely on the system Python, as long as
it's recent
enough. Ideally,
On 30-sep-2005, at 19:57, Stephen Langer wrote:
Hi --
I have a problem that is similar to one discussed in a thread from a
year ago,
http://mail.python.org/pipermail/distutils-sig/2004-September/
004160.html, but that thread doesn't quite have a resolution in the
archives.
I'd like to use dis
On 3-okt-2005, at 16:56, Stephen Langer wrote:
I don't know if this is possible, although I'd guess it is not.
That's too bad. Is there a reason for it? I'd volunteer to work on
modifying distutils so that it can build a .dylib, but I am not an
expert on library formats. I don't really
On 13-dec-2005, at 22:42, M.-A. Lemburg wrote:
> Bob Ippolito wrote:
>> On Dec 13, 2005, at 11:13 AM, M.-A. Lemburg wrote:
>> I'd like to focus attention on these distribution formats
>> that distutils is missing:
>>
>
> I'd like to another important candidate to the list:
>>>
On 20-dec-2005, at 15:40, M.-A. Lemburg wrote:
>
> I'm sure Apple will add support for uninstall soon. Even if not,
> we can easily add an uninstall script to the created package which
> then removes all traces of the installed package - much like
> bdist_wininst does in order to support uninstall
Hi,
Apple supports fat binaries on Mac OS X (they call them universal
binaries), that is binaries that contain executable code for multiple
architectures. In released version of the os this can be used to
build binaries and libraries that support both PPC and PPC64
architectures, which isn
On 4-jan-2006, at 22:26, Bob Ippolito wrote:
> On Jan 4, 2006, at 12:51 PM, Ronald Oussoren wrote:
>
>> Apple supports fat binaries on Mac OS X (they call them universal
>> binaries), that is binaries that contain executable code for multiple
>> architectures. In release
On 4-jan-2006, at 22:48, Bob Ippolito wrote:
>
> On Jan 4, 2006, at 1:38 PM, Ronald Oussoren wrote:
>
>>
>> On 4-jan-2006, at 22:26, Bob Ippolito wrote:
>>
>>> On Jan 4, 2006, at 12:51 PM, Ronald Oussoren wrote:
>>>
>>>> Apple su
On 23-jan-2006, at 17:31, Phillip J. Eby wrote:
>
> A little experimentation with the socket module shows that I can
> get the
> full list of mirror IPs from Python, so I've changed setuptools in
> SVN to
> just randomly select one to use, which should fix the sticking
> problem on
> Windows
On 23-jan-2006, at 19:09, Ian Bicking wrote:
> Has anyone tried anything that involves setting the distutils options
> (e.g., where to install libraries) from sitecustomize or some other
> Python location? I want to put in logic that is more complex than can
> be expressed in a configuration fil
Hi,
I tried to install setuptools 0.6b2 in my python2.5 installation, but
that doesn't seem to work. The ez_setup.py installation method
doesn't work because there is no egg for python2.5, therefore I
downloaded the sources and ran 'python2.5 setup.py install'.
This results in this followin
On Jun 29, 2006, at 10:43 PM, Phillip J. Eby wrote:
At 04:13 PM 6/29/2006 +0100, Paul Moore wrote:
Agreed. But in the absence of a standard, supporting package authors'
existing approaches, which work with other distutils mechanisms,
seems
like a reasonable requirement.
Anything that the
Hi,
I'm building a tool that interfaces with PyPI and noticed that while
it is possible to fetch a lot of information through XML-RPC, the MD5
checksum of files isn't amongst that.
Ronald
smime.p7s
Description: S/MIME cryptographic signature
___
On Jul 11, 2006, at 5:17 PM, Jorge Vargas wrote:
> noone cares about this? it's a bug so simple to fix
There's loads of bugs and patches in the python tracker, and only a
limited amount of time that people work on python. The patch you
mentioned also sounds like a fix for a very limited
On Jul 14, 2006, at 1:56 AM, Robin Bryce wrote:
>> Shove the data in a foopackagedata package
>> which goes in a separate egg and throw a trivial __init__.py in
>> there.
>
> Yes, exactly. And I get the separate zip_safe as and added bonus.
>
>> What compelling argument?
>
> Ok, I should have s
On Jul 28, 2006, at 2:36 AM, Michael Bayer wrote:
> MyghtyUtils-0.52/test/testbase.py
>
> however, when you run "python setup.py sdist" on an OS X machine
> (interestingly, *not* on a windows machine), the resulting tar/gz
> file contains an extra file:
>
> MyghtyUtils-0.52/test/._Container.
On Jul 29, 2006, at 6:31 AM, Michael Bayer wrote:
> mac specific ? i dont think so. however, perhaps something in
> the file
> is being incorrectly construed as mac-specific (but still, I dont
> think
> so).
>
> heres the code:
That's not relevant, that is the data fork of the file. The f
On Jul 30, 2006, at 10:43 AM, Sergei Emantayev wrote:
> Hello,
>
> I'm trying to install the Distutils libarary since it does not
> included in my python installation. I run Suse linux. I have python
> 2.4. I've downloaded the distutils version 1.0.2 (the latest one).
> When I run 'python s
On Aug 4, 2006, at 11:36 AM, Martijn Faassen wrote:
Hey,
Any feedback on this? Nobody cares that Python eggs compiled with a
linux distribution version of Python don't run on hand-compiled
versions
of Python, and vice versa? I added [setuptools] to the topic in case
that's the convention to
Hi,
Several python packages, such as Numeric, will install header files
during installation. It seems to me that the best way to support this
in a world of eggs is to add those include files to eggs and teach
setuptools to use those includefiles in build_ext.
The attached patch does just
On 6-aug-2006, at 19:49, Phillip J. Eby wrote:
> At 04:23 PM 8/6/2006 -0700, Ronald Oussoren wrote:
>> Hi,
>>
>> Several python packages, such as Numeric, will install header files
>> during installation. It seems to me that the best way to support this
>> i
On Saturday, September 09, 2006, at 04:07AM, primco <[EMAIL PROTECTED]> wrote:
>
>I would love this as well, as I'm in a situation where setuptools is
>forbidden and I need to distribute Python apps like TurboGears and Pylons
>with loads of dependencies.
Why is setuptools forbidden? Is the the
r libraries and still have a pretty simple install
because the dependencies are written down in a machine-readable way
and a tool (setuptools) can act on that.
IIRC both the setuptools documentation and the list archives contain
descriptions on how to achieve multiple self-contained python
On Oct 14, 2006, at 6:27 PM, Robert Kern wrote:
Jay Parlar wrote:
I've tried asking this on the numpy list (a few times), but
unfortunately no response. Since the error *appears* to be inside
distutils, I thought maybe someone here would recognize it.
No, it's not a problem in distutils. Ple
On Oct 14, 2006, at 6:31 PM, Phillip J. Eby wrote:
At 11:10 AM 10/14/2006 -0400, Jay Parlar wrote:
I've tried asking this on the numpy list (a few times), but
unfortunately no response. Since the error *appears* to be inside
distutils, I thought maybe someone here would recognize it.
Nope, i
On Monday, October 16, 2006, at 03:11PM, Jay Parlar <[EMAIL PROTECTED]> wrote:
>> On Oct 14, 2006, at 6:27 PM, Robert Kern wrote:
>
>> Actually it is a problem in disutils, one that is AFAIK fixed in
>> 2.4.4c1 (and the same patch is in the 2.5 branch and on the trunk).
>>
>> What happens is tha
On Oct 25, 2006, at 8:05 PM, Christopher Blunck wrote:
the trouble here with that %install section is that the python modules
get bytecompiled and thus turned into native code. i'd prefer for
that not to happen, so i have written my own install.sh script and i
provide that to my python setup
On 9 Nov 2006, at 6:43 PM, Thomas Heller wrote:
Ok, easy_install is really cool.
Installing most of the packages (*) that one needs with easy_install
makes the wish grow to use easy_install as a complete solution.
So, why can't easy_install manage the packages that I have
installed in
the
On Monday, November 27, 2006, at 03:01PM, "Antoine Pitrou" <[EMAIL PROTECTED]>
wrote:
>
>Is there a clean way to have setuptools do a rebuild when the .h file is
>changed?
In recent versions of python (at least 2.4, maybe also 2.3) there's an
"depends" argument for Extension where you can lis
On Dec 8, 2006, at 5:24 PM, Ilias Lazaridis wrote:
My requirement is to have no additional installation steps after an
svn-checkout (or unzip).
You could include the egg-info in your repository and distribution
archive.
Ronald
smime.p7s
Description: S/MIME cryptographic signature
Hi,
I have a setup.py that has some projects in the install_requires list
that setuptools cannot find yet (I haven't build the eggs yet) and
noticed something odd. When there is not yet an .egg-info directory
for my project everything is fine, I can run distutils commands
(except install
On 4 Jan, 2007, at 22:44, Phillip J. Eby wrote:
At 04:24 PM 1/2/2007 +0100, Ronald Oussoren wrote:
Hi,
I have a setup.py that has some projects in the install_requires list
that setuptools cannot find yet (I haven't build the eggs yet) and
noticed something odd. When there is not yet an
On 6 Jan, 2007, at 2:07, Phillip J. Eby wrote:
At 04:35 PM 1/5/2007 -0800, Scott Robertson wrote:
I'm trying to create a package that provides a setuptool command
that will
compile idl files when you run python setup.py build or python
setup.py
install.
I've figured out how to add an addi
Philip,
The attached patched replaces pkg_resources._macosx_vers by a function that
directly parses the relevant XML file instead of using sw_vers. The patch is an
svn diff relative to the trunk.
The main reason I prefer this version is that I'm debugging some C code in a
project using setupto
On 14 Feb, 2007, at 1:15, Phillip J. Eby wrote:
> At 02:35 PM 2/13/2007 -0800, Ronald Oussoren wrote:
>> Philip,
>>
>> The attached patched replaces pkg_resources._macosx_vers by a
>> function that directly parses the relevant XML file instead of
>> using
On 16 Sep, 2007, at 21:44, Ian Bicking wrote:
> Ronald Oussoren wrote:
>> On 15 Sep, 2007, at 18:09, Ian Bicking wrote:
>>> Hi all. I'm kind of giving up on workingenv, and have started
>>> working
>>> from virtual-python as a basis instead
&g
1 - 100 of 182 matches
Mail list logo
