On 19 July 2013 20:48, Steve Dower wrote:
>> From: Oscar Benjamin
>> I don't know whether or not you intend to have wrappers also work for
>> Python 2.7 (in a third-party package perhaps) but there is a slightly
>> subtle point to watch out for when non-ASCII characters in sys.argv
>> come into pl
> From: Oscar Benjamin
> I don't know whether or not you intend to have wrappers also work for
> Python 2.7 (in a third-party package perhaps) but there is a slightly
> subtle point to watch out for when non-ASCII characters in sys.argv
> come into play.
>
> Python 2.x uses GetCommandLineA and 3.x
Oscar Benjamin gmail.com> writes:
> Python 2.x uses GetCommandLineA and 3.x uses GetCommandLineW. A
> wrapper to launch 2.x should use GetCommandLineA and CreateProcessA to
> ensure that the 8-bit argument strings are passed through unaltered.
> To launch 3.x it should use the W versions. If not
Donald Stufft stufft.io> writes:
> I don't think it was speed of parsing the file that was his concern,
rather that
> if it's a separate file that only exists when there are entry points, then you
> don't have to open a file for every installed distribution.
OK. In that case, exports.json would
On Jul 17, 2013, at 3:40 AM, Vinay Sajip wrote:
> It has been suggested by PJE that the
> exports information should be in a separate file for speed of searching -
> though that suggestion was made in a pre-JSON world, where the speed of
> parsing the metadata wasn't C-assisted.
I don't think i
Nick Coghlan gmail.com> writes:
> Actually, it may be better to have a top level "scripts" field, distinct
from a general export mechanism.
> I'm seeing value in an exports mechanism, though.
The exports functionality is important and used enough to warrant support in
the PEP, and not only for t
On 17 Jul 2013 10:03, "Donald Stufft" wrote:
>
>
> On Jul 16, 2013, at 8:00 PM, Nick Coghlan wrote:
>
>>
>> On 17 Jul 2013 04:19, "Vinay Sajip" wrote:
>> >
>> >
>> >
>> > >If I were writing a firm proposal, I'd go for something like entry
points as metadata
>> >
>> > My extended metadata already
On Jul 16, 2013, at 8:00 PM, Nick Coghlan wrote:
>
> On 17 Jul 2013 04:19, "Vinay Sajip" wrote:
> >
> >
> >
> > >If I were writing a firm proposal, I'd go for something like entry points
> > >as metadata
> >
> > My extended metadata already covers this, though I use the name "exports"
> > (s
On 17 Jul 2013 04:19, "Vinay Sajip" wrote:
>
>
>
> >If I were writing a firm proposal, I'd go for something like entry
points as metadata
>
> My extended metadata already covers this, though I use the name "exports"
(suggested by PJE) because you can share not just code but data, and "entry
points
>I really don't want the wrappers to be present in the wheel, because if they
>are the wheel becomes architecture-specific. Also, consider that Unix targets
>should have the actual scripts written with no extension, whereas Windows
>targets should have foo-script.py and foo.exe. That should be d
On 16 July 2013 22:41, Vinay Sajip wrote:
> If the PEP is updated to include the exports, they should be in the wheel
> no
> matter which tool builds it. Then in theory distlib could generate the
> scripts during installation, but there are a lot of options to consider -
> did setuptools put them
Paul Moore gmail.com> writes:
> I'm not 100% sure what your proposal is here - I'm confused about the precise
> roles of setup.py/setuptools as "builder" vs distil as "builder" vs distlib
> as "wheel builder" vs distlib as "wheel installer". I'll try to get some time
> in the next day or so to re
On 16 July 2013 20:21, Vinay Sajip wrote:
> > defined in exports; it should be a five-minute job to ensure that
> scripts in
> > exports are excluded from this, when building wheels.
>
> It was a quick job, but thinking about it, I should probably update the
> Wheel.install API to take an optiona
Vinay Sajip yahoo.co.uk> writes:
> defined in exports; it should be a five-minute job to ensure that scripts in
> exports are excluded from this, when building wheels.
It was a quick job, but thinking about it, I should probably update the
Wheel.install API to take an optional process_exports=Tr
There are two versions of launchers primarily because of my naiveté when
addressing the UAC issue. 64-bit launchers were exempt from the UAC
restrictions that caused them to launch in a separate window. I believed
this to be a proper fix, when in fact those still using 32-bit launchers
were still e
Paul Moore gmail.com> writes:
> The only other part of the equation is to ensure that wheel *builders* do
> not put setuptools-generated entry point wrappers into the scripts
> directory. Before I embarrass myself again () is this also something you
> already have implemented in distlib?
No, be
On 16 July 2013 19:18, Vinay Sajip wrote:
>
> >If I were writing a firm proposal, I'd go for something like entry points
> as metadata
>
> My extended metadata already covers this, though I use the name "exports"
> (suggested by PJE) because you can share not just code but data, and "entry
> poin
>If I were writing a firm proposal, I'd go for something like entry points as
>metadata
My extended metadata already covers this, though I use the name "exports"
(suggested by PJE) because you can share not just code but data, and "entry
points" generally implies code. The current version of
On 16 July 2013 16:51, Vinay Sajip wrote:
> Paul Moore gmail.com> writes:
>
> > FWIW, I believe that the whole "scripts" directory as a concept is too
> > platform-specific. The only real use for it is to expose CLI applications
>
> Well, you can also expose GUI applications this way, though the
Paul Moore gmail.com> writes:
> FWIW, I believe that the whole "scripts" directory as a concept is too
> platform-specific. The only real use for it is to expose CLI applications
Well, you can also expose GUI applications this way, though the applications
are fewer - Qt applications could easily
On 16 July 2013 16:22, Paul Moore wrote:
> On 16 July 2013 16:09, Oscar Benjamin wrote:
>
>> However, if you also want the program name to be invokable from e.g.
>> subprocess with shell=False or from git-bash or Cygwin or many other
>> things then neither .bat files nor PATHEXT are sufficient. W
On 16 July 2013 16:09, Oscar Benjamin wrote:
> If you only want the program to be invokable from cmd and PowerShell*
> then a .bat file should be fine. Depending on file extension to invoke
> .py files with py.exe is subject to input/output redirection bugs on
> some windows systems (this is solv
On 16 July 2013 15:01, Vinay Sajip wrote:
> Vinay Sajip yahoo.co.uk> writes:
> >
> > Not true for distlib - it doesn't add .exe wrappers to wheels at build
> time
> > It adds them to the target directory when installing under Windows. (You
> > can also choose not to install any wrappers.)
>
> S
On 16 July 2013 14:38, Paul Moore wrote:
> On 16 July 2013 14:30, Ronald Oussoren wrote:
>>
>> > I think the correct solution is to explicitly have declarative support
>> > for "console script entry point" metadata in PEP 426, as well as having
>> > tools like bdist_wheel and distil do some expli
Vinay Sajip yahoo.co.uk> writes:
>
> Not true for distlib - it doesn't add .exe wrappers to wheels at build time
> It adds them to the target directory when installing under Windows. (You
> can also choose not to install any wrappers.)
Sorry, some misinformation there - distlib does do this whe
Need a script that visits all the console-script entry points to
regenerate the wrappers. Then there are also the non-console-scripts
scripts...
I consider scripts as an optional convenience, but I suppose that
isn't always the case.
On Tue, Jul 16, 2013 at 9:53 AM, Vinay Sajip wrote:
> Paul Moo
Paul Moore gmail.com> writes:
> Yes, Nick pointed me at that part of the PEP. Nobody's doing that at the
> moment, and exes are being added to the wheels at wheel build time, which
> is also wrong.
Not true for distlib - it doesn't add .exe wrappers to wheels at build time
:-) It adds them to th
On 16 July 2013 23:29, Paul Moore wrote:
> As I said in my other email, I think this is subtle enough that we need a
> stdlib implementation to stop people making mistakes like this. It's
> certainly not fair to expect a mostly-Unix development team to get this sort
> of Windows arcana right witho
On 16 July 2013 14:30, Ronald Oussoren wrote:
> > I think the correct solution is to explicitly have declarative support
> for "console script entry point" metadata in PEP 426, as well as having
> tools like bdist_wheel and distil do some explicit backward compatibility
> hacking to remove legacy
On 16 July 2013 14:08, Paul Moore wrote:
> PS There is still the proviso that I haven't tested my assumption that the
> separate 32 and 64 bit wrappers are *needed* (setuptools and distlib use
> them, so I think it's a valid assumption, but I need to test). I will try
> to get time to check that
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
> > versions of pip...
>
> Couldn't you
On 16 July 2013 14:21, Nick Coghlan wrote:
> On 16 July 2013 23:08, Paul Moore wrote:
> > Nick: See the above point re PEP 426 - do you agree that this needs
> > addressing in Metadata 2.0?
>
> I believe Daniel already covered it in PEP 427 - rather than baking
> the entry point wrappers into th
On 16 July 2013 23:08, Paul Moore wrote:
> Nick: See the above point re PEP 426 - do you agree that this needs
> addressing in Metadata 2.0?
I believe Daniel already covered it in PEP 427 - rather than baking
the entry point wrappers into the wheel, installers can generate any
needed entry point
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 versions of pip...
>
> Couldn't you just ship both variants of the exe wrappers in a single
34 matches
Mail list logo
