At 11:40 PM 9/23/2005 -0400, Fred Drake wrote:
>On 9/23/05, Richard Jones <[EMAIL PROTECTED]> wrote:
> > Distutils metadata capture is implemented in the Python core. We would
> want to
> > implement any name restrictions there, surely? Otherwise people only get an
> > error when attempting to use
On 9/23/05, Richard Jones <[EMAIL PROTECTED]> wrote:
> Distutils metadata capture is implemented in the Python core. We would want to
> implement any name restrictions there, surely? Otherwise people only get an
> error when attempting to use setuptools or register with PyPI, which would be
> just
On Sat, 24 Sep 2005 10:10 am, Phillip J. Eby wrote:
> Okay, so I still don't understand why this requires "changing Python
> itself". Could you explain?
Distutils metadata capture is implemented in the Python core. We would want to
implement any name restrictions there, surely? Otherwise people
At 03:45 PM 9/23/2005 -0700, Trent Mick wrote:
> > > > Where does setuptools install its wrapper executables? (The
> > > > usual \Python24\Scripts directory isn't added to PATH by the
> > > > installer).
> > >
> > >setuptools installs them in PythonXY\Scripts.
> >
> > Unless you set --install-scrip
At 08:45 AM 9/24/2005 +1000, Richard Jones wrote:
>On Sat, 24 Sep 2005 01:40 am, Phillip J. Eby wrote:
> > At 01:37 PM 9/23/2005 +1000, Richard Jones wrote:
> > >I believe what you're proposing would require changing Python itself so it
> > >enforces restrictions on package names (ie. all lower-cas
> > > Where does setuptools install its wrapper executables? (The
> > > usual \Python24\Scripts directory isn't added to PATH by the
> > > installer).
> >
> >setuptools installs them in PythonXY\Scripts.
>
> Unless you set --install-scripts somewhere else, which you can do in a
> configuration fi
On Sat, 24 Sep 2005 01:40 am, Phillip J. Eby wrote:
> At 01:37 PM 9/23/2005 +1000, Richard Jones wrote:
> >I believe what you're proposing would require changing Python itself so it
> >enforces restrictions on package names (ie. all lower-case, very limited
> >punctuation, no whitespace). I think t
At 11:57 PM 9/23/2005 +0200, Martijn Faassen wrote:
>I've been looking at Python eggs, easy install and setuptools with a lot
>of interest -- very impressive work. I've been thinking of packaging
>lxml with it, and, on the larger scale, look into packaging Zope 3 with it.
>
>Concerning lxml I run i
Hi there,
I've been looking at Python eggs, easy install and setuptools with a lot
of interest -- very impressive work. I've been thinking of packaging
lxml with it, and, on the larger scale, look into packaging Zope 3 with it.
Concerning lxml I run into a few questions however.
lxml depends o
At 09:38 PM 9/23/2005 +0200, Thomas Heller wrote:
>- When I run 'easy_install ctypes', the behaviour depends on the current
>directory. If I run this when the current dir contains a 'ctypes'
>subdirectory, it doesn't search pypi^H^H^H^HCheeseShop for this name,
>instead it seems to attempt to ins
- When I run 'easy_install ctypes', the behaviour depends on the current
directory. If I run this when the current dir contains a 'ctypes'
subdirectory, it doesn't search pypi^H^H^H^HCheeseShop for this name,
instead it seems to attempt to install from source in that directory.
Is that intended?
Title: FW: Distributing Python Modules - Error using foo.py in section 2.1 - Corrected
Greg
We do not have admin rights for our workstations here. After I was able to temporarily obtain admin rights and add python to the Path, your example works.
Thanks.
-Original Message---
Title: Distributing Python Modules - Error using foo.py in section 2.1
Greg Ward,
I am reading the documentation you wrote titled "Distributing Python Modules". In section 2.1 (A Simple Example), I made a simple script named foo.py but I am not able to get it running following the ste
At 03:07 PM 9/23/2005 +0200, Thomas Heller wrote:
>Paul Moore <[EMAIL PROTECTED]> writes:
>
> > On 9/17/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >> However, after reflection, I think now that -m probably only really makes
> >> sense for stdlib modules, since projects using setuptools can now
At 01:37 PM 9/23/2005 +1000, Richard Jones wrote:
>On Fri, 23 Sep 2005 01:32 pm, Phillip J. Eby wrote:
> > I'd like to encourage moving towards mangling the *keys* themselves, in
> > order to be robust in the face of typos. I think allowing random
> > punctuation and upper/lower case to distinguis
Paul Moore <[EMAIL PROTECTED]> writes:
> On 9/17/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> However, after reflection, I think now that -m probably only really makes
>> sense for stdlib modules, since projects using setuptools can now get all
>> the benefits of -m without any of the drawback
On 9/19/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> In essence, the problem is that Python adds all .pth-specified paths to the
> *end* of sys.path, meaning that system-installed packages in the stdlib or
> site-packages take precedence over anything else you can install, except
> for directori
On 9/17/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> However, after reflection, I think now that -m probably only really makes
> sense for stdlib modules, since projects using setuptools can now get all
> the benefits of -m without any of the drawbacks, without even writing any
> __name__=='__ma
18 matches
Mail list logo
