Nick Coghlan ncoghlan at gmail.com writes:
I previously thought distlib was going to be the repository for the
agreed, stable, this is going to happen stuff. It's OK that I was
wrong - I think you're right that somewhere is needed as an
experimental location to show some of the
Am 20.08.2013 19:39, schrieb PJ Eby:
I thought that at one point you (Thomas) had come up with a way to
load modules into memory from a zipfile without needing to extract
them. Was that you? If so, how did that work out?
To give a definite answer, after thinking it over:
It works, for quite
Disclaimer: everything I say below about pip is ultimately up to the
pip devs. I'm just pointing out what I think makes sense, and my
reading of Donald's comments means that I expect he would feel the
same way.
On 22 August 2013 17:22, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan
Nick Coghlan ncoghlan at gmail.com writes:
standard library is a mistake - the PyXML debacle shows us that. If
the API is different (even if that means a strict subset), then it
needs a different name.
I'm not really hung up about a specific name - what's in a name?
It has nothing to do
On 23 August 2013 00:19, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
When I made that suggestion, I misunderstood your plans for distlib.
If pip are only adopting a subset of it, they can't use the same name,
or people will get confused.
I can
On 22 August 2013 16:04, Nick Coghlan ncogh...@gmail.com wrote:
The next step is up to the pip folks - if they think adopting distlib
wholesale makes sense for them, fine, I have no direct say in that. If
they decide to make a piplib instead, to expose a public API for an
updated version of
Donald Stufft donald at stufft.io writes:
Mounting Wheels seems like a bad idea, it was one of the things Daniel
explicitly removed (since Wheels are basically cleaned up eggs). Adding
it back in ex post facto seems like it's an idea that's going down the wrong
track.
Like I said, the sky
On 21 August 2013 07:36, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Donald Stufft donald at stufft.io writes:
Mounting Wheels seems like a bad idea, it was one of the things Daniel
explicitly removed (since Wheels are basically cleaned up eggs). Adding
it back in ex post facto seems like
Paul Moore p.f.moore at gmail.com writes:
I'm concerned that you need extra metadata (not described in the wheel
spec) to do this. It means that there are in effect two subtly different
types of wheel. To be specific, if I create a wheel for (say) pyzmq using
distil, and mount it, everything
On Aug 21, 2013, at 3:32 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Paul Moore p.f.moore at gmail.com writes:
I'm concerned that you need extra metadata (not described in the wheel
spec) to do this. It means that there are in effect two subtly different
types of wheel. To be specific,
On 21 August 2013 08:45, Donald Stufft don...@stufft.io wrote:
My basic problem is if the library we're pointing at to be the reference
implementation of all of these things is adding new features it's
confusing what
is standard and what are just distlib's extensions.
So basically I want
On Aug 21, 2013, at 4:07 AM, Paul Moore p.f.mo...@gmail.com wrote:
OK, so here's a concrete question for distutils-sig. If I want to use wheels
in my app (built them, install them, whatever) what should I use as my
reference implementation. I don't want to implement the code myself, I just
Donald Stufft donald at stufft.io writes:
However what I don't really want is to be using someones personal testbed
for features they think is cool. There's nothing *wrong* with you trying
new ideas out in distlib, it just means that distib isn't the library I
want to build tooling around.
On 21 August 2013 09:09, Donald Stufft don...@stufft.io wrote:
On Aug 21, 2013, at 4:07 AM, Paul Moore p.f.mo...@gmail.com wrote:
OK, so here's a concrete question for distutils-sig. If I want to use
wheels in my app (built them, install them, whatever) what should I use as
my reference
On Aug 21, 2013, at 4:23 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Donald Stufft donald at stufft.io writes:
However what I don't really want is to be using someones personal testbed
for features they think is cool. There's nothing *wrong* with you trying
new ideas out in distlib, it
On 21 August 2013 09:56, Donald Stufft don...@stufft.io wrote:
ISTM distlib is not yet that reference library - it's just another
library
for most people, judging from the low level of feedback I've had overall.
That's totally fine. We just need to be clear that it's not the reference
On Aug 21, 2013, at 5:27 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 21 August 2013 09:56, Donald Stufft don...@stufft.io wrote:
ISTM distlib is not yet that reference library - it's just another library
for most people, judging from the low level of feedback I've had overall.
That's
On 21 August 2013 10:29, Donald Stufft don...@stufft.io wrote:
Can you send me a list (or post them here) of what issues you've hit? The
biggest one i'm aware of is the scripts problem which is a fundamental
problem with the 1.0 Wheel (or rather that any library with console entry
points
On Aug 21, 2013, at 5:46 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 21 August 2013 10:29, Donald Stufft don...@stufft.io wrote:
Can you send me a list (or post them here) of what issues you've hit? The
biggest one i'm aware of is the scripts problem which is a fundamental
problem with
On 21 August 2013 10:48, Donald Stufft don...@stufft.io wrote:
I think Wheel files are (and should be) independent of the particular
metadata version used. That file should contain the required information in
order to know what version of the metadata is included with the Wheel. This
means
On Aug 21, 2013, at 6:17 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 21 August 2013 10:48, Donald Stufft don...@stufft.io wrote:
I think Wheel files are (and should be) independent of the particular
metadata version used. That file should contain the required information in
order to know
On Aug 21, 2013, at 6:29 AM, Donald Stufft don...@stufft.io wrote:
introspecting the author email address
Of course I wrote that and then did summary because the location of the author
email address changed between Metadata 1.x and 2.x and I didn't feel like
looking up the exact difference.
On 21 August 2013 11:30, Donald Stufft don...@stufft.io wrote:
On Aug 21, 2013, at 6:29 AM, Donald Stufft don...@stufft.io wrote:
introspecting the author email address
Of course I wrote that and then did summary because the location of the
author email address changed between Metadata 1.x
On Aug 21, 2013, at 6:36 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 21 August 2013 11:30, Donald Stufft don...@stufft.io wrote:
On Aug 21, 2013, at 6:29 AM, Donald Stufft don...@stufft.io wrote:
introspecting the author email address
Of course I wrote that and then did summary because
Paul Moore p.f.moore at gmail.com writes:
My problem is that as someone who wants to implement code that uses the
new features like wheels, I want a usable reference implementation that
covers the (agreed) standards. I don't particularly want my application
to incorporate support for
On Aug 21, 2013, at 6:56 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Paul Moore p.f.moore at gmail.com writes:
My problem is that as someone who wants to implement code that uses the
new features like wheels, I want a usable reference implementation that
covers the (agreed) standards. I
On 21 August 2013 11:56, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
But I think we have a reasonable consensus on how scripts should work,
Do we?
To the level of wheels builders should write metadata that defines the
scripts and wheel installers should generate the necessary wrappers then
Paul Moore p.f.moore at gmail.com writes:
Another one IIRC was that distlib didn't put entry-points.txt in the
.dist-info directory in the wheel (which breaks entry points). I think
that's fixed now (and again, the Wheel spec is silent on what is correct
behaviour here).
Right. The recent
Donald Stufft donald at stufft.io writes:
I think the way you view distlib and the way other are viewing distlib are
different (and that's ok). We just need to know what distlib is so we can
have reasonable expectations of it. What i'm getting from you is that, at
least right now, distlib
On Wed, Aug 21, 2013 at 8:01 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 21 August 2013 12:22, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Paul Moore p.f.moore at gmail.com writes:
Another one IIRC was that distlib didn't put entry-points.txt in the
.dist-info directory in the wheel (which
On Aug 21, 2013, at 9:02 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Donald Stufft donald at stufft.io writes:
I think the way you view distlib and the way other are viewing distlib are
different (and that's ok). We just need to know what distlib is so we can
have reasonable
Donald Stufft donald at stufft.io writes:
I think you're using a completely different definition of reference
implementation than I've ever seen used. A reference implementation
Quite possibly, but I feel justified in this case ... I'll say why below.
by definition cannot contain
On Aug 21, 2013, at 11:30 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Donald Stufft donald at stufft.io writes:
I think you're using a completely different definition of reference
implementation than I've ever seen used. A reference implementation
Quite possibly, but I feel justified
On 08/21/2013 03:29 AM, Donald Stufft wrote:
Can you send me a list (or post them here) of what issues you've hit?
The biggest one i'm aware of is the scripts problem which is a
fundamental problem with the 1.0 Wheel (or rather that any library with
console entry points cannot be universal).
On Wed, Aug 21, 2013 at 9:24 AM, Donald Stufft don...@stufft.io wrote:
An example is the wsgiref from the standard library.
It's an example, alright, but not for your side. ;-) The wsgiref
library doesn't just implement the spec, it implements a ton of
utility classes for use with the spec.
On Aug 21, 2013, at 12:31 PM, PJ Eby p...@telecommunity.com wrote:
Personally, I'm very happy to see Vinay's extensions, because they are
IMO important validations of whether the new specs are likely to be
useful for replacing all of setuptools' functionality. There are
people who need to
On 08/21/2013 10:32 AM, Daniel Holth wrote:
2) Wheel's decision to follow distutils' documentation rather than
distutils' behavior when it comes to the location for installing
data_files with relative paths; see
On Wed, Aug 21, 2013 at 11:52 AM, Carl Meyer c...@oddbird.net wrote:
On 08/21/2013 03:29 AM, Donald Stufft wrote:
Can you send me a list (or post them here) of what issues you've hit?
The biggest one i'm aware of is the scripts problem which is a
fundamental problem with the 1.0 Wheel (or
1) Wheel's conversion of - to _ in version strings embedded in
filenames, which breaks with setuptools precedent; see
https://github.com/pypa/pip/issues/1150 and
https://bitbucket.org/dholth/wheel/issue/78/wheel-rewrites-versions-preventing
No good solution to this one just yet.
not
Paul Moore p.f.moore at gmail.com writes:
That implies that any wheel reference implementation needs to expose APIs
for reading and writing the metadata to/from the wheel.
Not necessarily. For example, distlib's approach side-steps the need for such
a write API: you tell Wheel.build which
Nick Coghlan ncoghlan at gmail.com writes:
Right. I wasn't really aware Vinay was adding experimental ideas to
distlib, I thought it was just the proven stable core from distutils2,
plus support for the draft PEPs, with the experimental stuff entirely in
distil rather than in distlib.
I've
On 22 August 2013 08:12, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I've been up front about what's in distlib all along - check the overview
page in the distlib docs. Above all, I want the stuff I do to be *useful*,
rather than tick boxes here and there.
Right, you didn't do anything wrong,
Back from holidays, I read this very interesting discussion...
Am 14.08.2013 16:33, schrieb Nick Coghlan:
Aside from the lack of embedded C extension support (which could
likely be fixed if zipimport was migrated to Python code for 3.5),
...but I don't understand what you mean by this. Can
On 20 Aug 2013 04:22, Thomas Heller thel...@ctypes.org wrote:
Back from holidays, I read this very interesting discussion...
Am 14.08.2013 16:33, schrieb Nick Coghlan:
Aside from the lack of embedded C extension support (which could
likely be fixed if zipimport was migrated to Python code
Am 20.08.2013 15:42, schrieb Nick Coghlan:
Importing C extensions requires extracting them to a temp directory and
loading them from there. Trivial in Python, a pain in C. zipimport is
currently still written in C.
So what - zipimport is a builtin module (on Windows at least).
On 20 Aug 2013 09:18, Thomas Heller thel...@ctypes.org wrote:
Am 20.08.2013 15:42, schrieb Nick Coghlan:
Importing C extensions requires extracting them to a temp directory and
loading them from there. Trivial in Python, a pain in C. zipimport is
currently still written in C.
So what -
Am 20.08.2013 18:22, schrieb Nick Coghlan:
On 20 Aug 2013 09:18, Thomas Heller thel...@ctypes.org
mailto:thel...@ctypes.org wrote:
Am 20.08.2013 15:42, schrieb Nick Coghlan:
Importing C extensions requires extracting them to a temp directory and
loading them from there. Trivial in
On Tue, Aug 20, 2013 at 12:39 PM, Thomas Heller thel...@ctypes.org wrote:
Ok, now I understand. But the zipfile could contain a loader-module
for each extension which does something like this (this example extracts
and loads 'bz2.pyd'):
...
(py2exe for Python 3, which is work in progress,
Am 20.08.2013 19:39, schrieb PJ Eby:
On Tue, Aug 20, 2013 at 12:39 PM, Thomas Heller thel...@ctypes.org wrote:
Ok, now I understand. But the zipfile could contain a loader-module
for each extension which does something like this (this example extracts
and loads 'bz2.pyd'):
...
(py2exe for
Thomas Heller theller at ctypes.org writes:
Ok, now I understand. But the zipfile could contain a loader-module
for each extension which does something like this (this example extracts
and loads 'bz2.pyd'):
In distlib, I've built on top of the zipfile support to allow C extensions
to be
On Aug 20, 2013, at 8:57 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Thomas Heller theller at ctypes.org writes:
Ok, now I understand. But the zipfile could contain a loader-module
for each extension which does something like this (this example extracts
and loads 'bz2.pyd'):
In
I know I'm bike-shedding here, but my preference for extension would be
'.pye' as it indicates something to execute, but without indicating
exactly how (i.e. that it's via a separate launcher executable).
.pyx
that said, both .pye and .pyx are superior to .pyl (is that last
character an
.pyx
that said, both .pye and .pyx are superior to .pyl (is that last
character an ell, an eye or a one?)
I agree that .pyl is less readable/more confusable.
We can't use .pyx, though, as that is already used in the Python ecosystem for
Pyrex files (a forerunner of Cython).
Regards,
On 13 August 2013 23:30, Chris Barker - NOAA Federal
chris.bar...@noaa.govwrote:
On Tue, Aug 13, 2013 at 2:27 PM, Paul Moore p.f.mo...@gmail.com wrote:
3) I'd rather not have to mess with PATHEXT, and I particularly don't
want to have to tell my students to do it -- environment variables
Jason R. Coombs jaraco at jaraco.com writes:
This means that instead of installing, for example:
Scripts\my-command.exe
Scripts\my-command-script.py
Scripts\my-command.exe.manifest
Just to muddy the waters a little, I'd like to suggest an alternative
approach which doesn't appear
On 13 August 2013 20:58, Paul Moore p.f.mo...@gmail.com wrote:
On 13 August 2013 18:08, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 13 August 2013 17:33, Paul Moore p.f.mo...@gmail.com wrote:
On another point you mention, Cygwin Python should be using Unix-style
shell
script
On Wed, Aug 14, 2013 at 7:34 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Jason R. Coombs jaraco at jaraco.com writes:
This means that instead of installing, for example:
Scripts\my-command.exe
Scripts\my-command-script.py
Scripts\my-command.exe.manifest
Just to muddy the waters
On 14 August 2013 12:42, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
I do think, as I said before, that this needs some sort of policy-type
PEP on the standard approach for wrapping scripts, with all the pros and
cons of the various approaches documented and reviewed.
There have been
On 14 August 2013 13:57, PJ Eby p...@telecommunity.com wrote:
Thoughts?
Writing the script.py file means the current user needs write access
to a program installation directory, which is probably not a good
idea. Also, what if two instances are running, or you overwrite an
existing script
Better suggestion: just append a PEP 441 .pyz to the .exe, and no
IIUC PEP 441 is about tooling to create archives; don't we just need a
Python-compatible .zip (i.e. with a __main__.py)?
For bonus points, you can actually stick a compatibly-built wheel on
the end of the .exe instead, and
On 14 August 2013 09:58, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Better suggestion: just append a PEP 441 .pyz to the .exe, and no
IIUC PEP 441 is about tooling to create archives; don't we just need a
Python-compatible .zip (i.e. with a __main__.py)?
For bonus points, you can
On 14 August 2013 14:48, Paul Moore p.f.mo...@gmail.com wrote:
But I do see your point regarding things like subprocess. It's a shame, but
anything other than exes do seem to be second class citizens on Windows.
BTW, you mention bat files - it bugs me endlessly that bat files seem to
have a
On Wed, Aug 14, 2013 at 9:58 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
IIUC PEP 441 is about tooling to create archives; don't we just need a
Python-compatible .zip (i.e. with a __main__.py)?
I meant that it has a #! line before the zip part, so that the
launcher knows what Python to
On 14 August 2013 16:49, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
To give an example of where these subprocess issues might matter.
sphinx auto-generates Makefiles that call 'sphinx-build' with no
extension. The sphinx-build command has a setuptools .exe wrapper so
that it will be
On 14 August 2013 18:46, PJ Eby p...@telecommunity.com wrote:
Shouldn't naming the file .pyw already work today for that case?
Certainly, the .pyw extension is already suitable for manually
creating GUI scripts in a text editor. Unless there's something
special about how the 'pythonw'
On Wed, Aug 14, 2013 at 2:14 PM, Paul Moore p.f.mo...@gmail.com wrote:
.pyw files can be imported as modules, just like .py,
Darn. Okay, so another extension *is* needed if you want to be able
to make non-console apps runnable-but-not-importable. IIUC it should
by '.pywa' rather than '.pya',
On 13 August 2013 01:01, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Just a thought -- is there any need in this day and age
for extensions to be limited to 3 characters?
There's a bug affecting PowerShell, which Microsoft have pretty much
confirmed that they won't fix, which means that
On Mon, Aug 12, 2013 at 20:55 +, Vinay Sajip wrote:
Donald Stufft donald at stufft.io writes:
Hopefully this all will solve this problem, as it is right now if you use
setuptools entry points then Wheels erroneously pretend to be platform
agnostic.
That's not unreasonable, as long
Vinay Sajip vinay_sajip at yahoo.co.uk writes:
While distlib currently uses bespoke launchers, I plan to update it before
the next release to use the PEP 397 launcher compiled with SCRIPT_WRAPPER.
One more data point - the launcher currently used by distlib is found at
[1]. Since it doesn't
-Original Message-
From: Steve Dower [mailto:steve.do...@microsoft.com]
Sent: Monday, 12 August, 2013 15:03
Jason R. Coombs wrote:
6. Two to three files to do the job of one. In fact, the job isn't
much more than to invoke code elsewhere, so it seems ugly to require
as many as
On Tue, Aug 13, 2013 at 8:54 AM, Jason R. Coombs jar...@jaraco.com wrote:
1. Renames, deletes, and other actions must be synchronized.
Why are you manually deleting or altering executables? Why are you
renaming them at all?
I've been using .exe wrappers since they were written, and have never
On 13 August 2013 16:58, PJ Eby p...@telecommunity.com wrote:
5. Files in use can't be replaced. Because a Windows executable that's
in use
is not allowed to be overwritten,
But they can be renamed, and deleted afterwards. For example, when
updating, you can do the simple dance of:
1.
On 13 August 2013 17:33, Paul Moore p.f.mo...@gmail.com wrote:
On another point you mention, Cygwin Python should be using Unix-style shell
script wrappers, not Windows-style exes, surely? The whole point of Cygwin
is that it emulates Unix, after all... So I don't see that as an argument
On Tue, Aug 13, 2013 at 12:33 PM, Paul Moore p.f.mo...@gmail.com wrote:
This works, but is an ugly, fragile workaround. It's *not* a huge problem,
it's just how executables work on Windows, and all installers have to deal
with this dance (it's why a lot of things need a reboot to complete
On 13 August 2013 18:08, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 13 August 2013 17:33, Paul Moore p.f.mo...@gmail.com wrote:
On another point you mention, Cygwin Python should be using Unix-style
shell
script wrappers, not Windows-style exes, surely? The whole point of
Cygwin
Just $0.02 from a user...
I'm primarily an OS-X user these days, but have to do Windows once in
a while, and help others do Windows (including as an intro to Python
instructor)
Once I discovered setuptools develop mode, I never looked bak -- it
is simpl;y THE way to develop code, particularly if
On 13 August 2013 21:20, Chris Barker - NOAA Federal
chris.bar...@noaa.govwrote:
Conclusions:
1) an extra bunch of files is a on-issue for most users -- we just
need something that works.
Agreed - the extra files clutter is a relatively small issue.
2) the exe launcher is a bit fragile and
From: Distutils-SIG
[mailto:distutils-sig-bounces+jaraco=jaraco@python.org] On Behalf Of
Paul Moore
Sent: Tuesday, 13 August, 2013 17:28
In the interests of getting more concrete data, can I suggest that
setuptools add an off-by-default option, which can be set globally using a
config
On Tue, Aug 13, 2013 at 2:27 PM, Paul Moore p.f.mo...@gmail.com wrote:
3) I'd rather not have to mess with PATHEXT, and I particularly don't
want to have to tell my students to do it -- environment variables are
a pain, and somehow PATHEXT has been fragile for me (and I don't use
Cygwin)
On 11 Aug 2013 21:37, PJ Eby p...@telecommunity.com wrote:
On Sun, Aug 11, 2013 at 7:31 PM, Jason R. Coombs jar...@jaraco.com
wrote:
-Original Message-
From: Nick Coghlan [mailto:ncogh...@gmail.com]
Sent: Sunday, 11 August, 2013 17:14
We actually have a proposal on import-sig
On Mon, Aug 12, 2013 at 7:33 AM, Nick Coghlan ncogh...@gmail.com wrote:
Having pys and pyz for executable, but not importable (source and zip
archive forms) could be quite clean. In effect, the pys extension would
bring windows to parity with *nix, where no extension at all has
traditionally
On 12 August 2013 14:01, PJ Eby p...@telecommunity.com wrote:
This means that you can actually write source as a .pyz or .pwz file
on Windows, and it would Just Work -- *without any sys.path
modification*.
Conversely, you can right now rename a zipped file as xxx.py and it will be
run
On Mon, Aug 12, 2013 at 10:32 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 12 August 2013 14:01, PJ Eby p...@telecommunity.com wrote:
As far as zipped Python applications are concerned (pyz), these can be
created by just using a pys file containing a #! line prepended to the zip
file.
On 12 August 2013 16:35, Nick Coghlan ncogh...@gmail.com wrote:
Hm, here's a side thought: what if PyLauncher added the ability to
serve as a script wrapper, just like setuptools' existing wrappers?
Then setuptools could just copy py.exe or pyw.exe alongside a .pyl or
.pyw, and presto!
On 12 August 2013 11:21, PJ Eby p...@telecommunity.com wrote:
On Mon, Aug 12, 2013 at 10:32 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 12 August 2013 14:01, PJ Eby p...@telecommunity.com wrote:
As far as zipped Python applications are concerned (pyz), these can be
created by just using a
-Original Message-
From: Distutils-SIG [mailto:distutils-sig-
bounces+jaraco=jaraco@python.org] On Behalf Of PJ Eby
Sent: Monday, 12 August, 2013 11:22
On Mon, Aug 12, 2013 at 10:32 AM, Paul Moore p.f.mo...@gmail.com
wrote:
On 12 August 2013 14:01, PJ Eby
I know I'm bike-shedding here, but my preference for extension would be
'.pye' as it indicates something to execute, but without indicating exactly
how (i.e. that it's via a separate launcher executable).
+1 (I spent the whole time reading this thread thinking I'd prefer pye, or
maybe pyx
Jason R. Coombs wrote:
My preference is to reject the idea of the side-by-side executable launcher.
There are several downsides that I'm trying to avoid by moving away from the
executable:
[SNIP]
2. Executables that look like installers. If a launcher executable is used
and
Windows
On 12 August 2013 19:35, Steve Dower steve.do...@microsoft.com wrote:
And any reason we need a separate extension for pyw.exe? Can't that be
specified in the shebang?
The association specifies the exe to run, that exe then relaunches whatever
the shebang specifies. But it's the *initial*
On 12 August 2013 19:14, Jason R. Coombs jar...@jaraco.com wrote:
My preference is to reject the idea of the side-by-side executable
launcher.
There are several downsides that I'm trying to avoid by moving away from
the
executable:
Using a dedicated filetype and associated systemwide
On Mon, Aug 12, 2013 at 2:14 PM, Jason R. Coombs jar...@jaraco.com wrote:
-Original Message-
From: Distutils-SIG [mailto:distutils-sig-
bounces+jaraco=jaraco@python.org] On Behalf Of PJ Eby
Sent: Monday, 12 August, 2013 11:22
On Mon, Aug 12, 2013 at 10:32 AM, Paul Moore
Jason R. Coombs jaraco at jaraco.com writes:
My preference is to reject the idea of the side-by-side executable
launcher.
I agree that it's not ideal to have side-by-side executables, but how do you
propose to address PJE's point about older Python versions? You can't force
people to install
On Mon, Aug 12, 2013 at 4:04 PM, Paul Moore p.f.mo...@gmail.com wrote:
I would still like to see the standard be registered .pye (I'm happy with a
bikeshed of this colour) and .pwe extensions which are added to PATHEXT and
As long as we're discussing bikeshed colors, I'd like to
counterpropose
On Aug 12, 2013, at 4:04 PM, Paul Moore p.f.mo...@gmail.com wrote:
Also, of course, as was mentioned elsewhere in the thread, you need separate
wrapper exes for every architecture/platform you intend to support. And
unless the wrappers are added at install time, wrapped scripts change a
On Mon, Aug 12, 2013 at 4:29 PM, Donald Stufft don...@stufft.io wrote:
Hopefully this all will solve this problem, as it is right now if you use
setuptools entry points then Wheels erroneously pretend to be platform
agnostic.
IMO it's okay to give up having ready-to-use scripts in a
PJ Eby wrote:
(Granted, I can see reasons for not wanting to use the same extension
for source and zipped versions, mostly in the area of tools other than
pylauncher, but if you do have different extensions then there have to
be *four*, due to console vs. windowed and source vs. zipped.)
Just
On Sun, Aug 11, 2013 at 10:38 AM, Jason R. Coombs jar...@jaraco.com wrote:
In Setuptools 1.0 (currently in beta), I've added an experimental, opt-in
feature to install pure Python launcher scripts on Windows instead of
installing a launcher executable for each script, with the intention that
On Sun, Aug 11, 2013 at 12:17 PM, PJ Eby p...@telecommunity.com wrote:
May I suggest an option 5 instead? Use the new .pyz (or .pyzw for
non-console apps) as a zipped Python application. .pyz files aren't
importable, but *are* executable. That's basically all that's needed
to prevent
-Original Message-
From: PJ Eby [mailto:p...@telecommunity.com]
Sent: Sunday, 11 August, 2013 12:17
Here's another problem with #1: you will break single-directory standalone
portable app installs, where you use easy_install -mad somedir to
install all
of an app's dependencies
On Sun, Aug 11, 2013 at 1:58 PM, Jason R. Coombs jar...@jaraco.com wrote:
This sounds like a suitable idea, but as you mention in a subsequent
message, this format has issues with sys.path assumptions as well.
Meh. It's basically, a one-line fix in the __main__.py, i.e.:
import
1 - 100 of 103 matches
Mail list logo
