Michael Urman gmail.com> writes:
> You can certainly jump through all these hoops, but the pieces here
> are much more suited towards a component definition that can be shared
> among multiple products. If the component always installs to the same
> place, has the same GUID, and otherwise only ch
On Tue, Jul 5, 2011 at 03:01, Vinay Sajip wrote:
> Were those other Windows apps packaged as .msi, or .exe? AFAICT, although you
> can embed an MSI inside another one, the practice of concurrent/nested
> installations is strongly discouraged by Microsoft - see http://goo.gl/FJx1S
> (Rule 20).
Rig
Mark Hammond gmail.com> writes:
> Or an MSI installer may be able to offer a "repair" feature without too
> much pain.
A few more observations to do with installation:
1. It's been mentioned that a standalone version should be available for use
with earlier Python versions. This could be done
On 5 July 2011 03:26, Nick Coghlan wrote:
> On Tue, Jul 5, 2011 at 12:12 PM, Mark Hammond
> wrote:
>> If the launcher is such that we can unconditionally recommend its use, IMO
>> we should just install it with Python. I'll go with the consensus though...
>
> I've installed other WIndows apps t
Nick Coghlan gmail.com> writes:
> I've installed other WIndows apps that create multiple add/remove
> programs entries from a single installer. I believe people are
> suggesting a similar thing here (i.e. have the launcher installed
> automatically when installing python, but create a separate ad
On 2/07/2011 5:16 PM, I wrote:
Given [the C implementation] is now ahead of the Python
reference impl, I wonder if we should just drop all wording about that
reference impl and just treat the C impl as canonical?
I'm looking to update the PEP based on this discussion - does anyone
object to t
On Tue, Jul 5, 2011 at 12:12 PM, Mark Hammond wrote:
> If the launcher is such that we can unconditionally recommend its use, IMO
> we should just install it with Python. I'll go with the consensus though...
I've installed other WIndows apps that create multiple add/remove
programs entries from
On 5/07/2011 11:23 AM, Greg Ewing wrote:
Vinay Sajip wrote:
the installation of a pre-3.3 version of Python after Python 3.3 is
installed with the launcher will, if the user selects "Register
Extensions",
hijack the laumcher's associations to that earlier Python. Then bye
bye launcher
I don't
Vinay Sajip wrote:
the installation of a pre-3.3 version of Python after Python 3.3 is
installed with the launcher will, if the user selects "Register Extensions",
hijack the laumcher's associations to that earlier Python. Then bye bye launcher
I don't see how anything can be done about that. I
One more thing about associations - we've got pyw.exe for Python.NoConFile
and py.exe for Python.file, but how do we handle Python.CompiledFile? It
doesn't really make sense to have the association not handled by the launcher.
Unfortunately, of course, both pyw and py compile to pyo, so we don't kn
Mark Hammond gmail.com> writes:
> > It might be better to look in the registry for other Python
> > installations and ask the user which one to restore if there
> > is more than one. Trying to restore the "last" one would be
> > prone to breakage if the user didn't uninstall versions in
> > preci
On Mon, Jul 4, 2011 at 2:27 AM, Mark Hammond wrote:
> While that makes alot of sense, the fact we are already "broken" in exactly
> the same way means I hope we can treat the restoration of associations as a
> separate issue - a worthwhile one, but not a pre-requisite for this PEP
> being approved
On 4/07/2011 3:59 PM, Greg Ewing wrote:
Mark Hammond wrote:
On 2/07/2011 7:08 PM, Vinay Sajip wrote:
perhaps we could remember the last non-launcher association when we
install the launcher,
It might be better to look in the registry for other Python
installations and ask the user which on
Mark Hammond wrote:
On 2/07/2011 7:08 PM, Vinay Sajip wrote:
perhaps we could remember the last non-launcher association when
we install the launcher,
It might be better to look in the registry for other Python
installations and ask the user which one to restore if there
is more than one. T
On 3 July 2011 19:20, Vinay Sajip wrote:
> Paul Moore gmail.com> writes:
>
>> OK, having looked through this, it looks pretty solid to me. I might
>> try installing Vinay's implementation and seeing how it feels in use,
>> as well...
>
> Do have a play, it would be nice to get feedback. It's only
Paul Moore gmail.com> writes:
> OK, having looked through this, it looks pretty solid to me. I might
> try installing Vinay's implementation and seeing how it feels in use,
> as well...
Do have a play, it would be nice to get feedback. It's only available as source,
though - is that OK?
> I'd
On 30 June 2011 13:50, Paul Moore wrote:
> On 30 June 2011 12:13, Michael Foord wrote:
>> I have that email (the update one from Mark not the silent nodding from Tim)
>> still sitting in my inbox waiting for me to properly read through and
>> comment on... Sorry for being useless, I'll try and mo
Mark Hammond gmail.com> writes:
> But this only happens when they install a later version, then uninstall
> the later one and continue to use the old one. I'd suggest that is (a)
> rare and (b) possibly already broken (ie, the old association may not be
> restored now). If the old associatio
Mark Hammond gmail.com> writes:
> I'm not fundamentally opposed to doing something better here - I'm just
> trying to avoid this kind of stuff being a requirement for acceptance.
> If you are more familiar with the installer than I and feel it can be
> done simply, then I'm happy for you to go
On 2/07/2011 7:08 PM, Vinay Sajip wrote:
Mark Hammond gmail.com> writes:
The PEP does say "if possible, should be installed somewhere likely to
already be on the system PATH (eg., the Windows System32) directory."
It is silent about what to do when that isn't possible, but I'd think it
OK if
Mark Hammond gmail.com> writes:
> The PEP does say "if possible, should be installed somewhere likely to
> already be on the system PATH (eg., the Windows System32) directory."
> It is silent about what to do when that isn't possible, but I'd think it
> OK if the launcher was installed directl
On 1/07/2011 7:20 PM, Vinay Sajip wrote:
Mark Hammond gmail.com> writes:
The intention is that there only be a single launcher, as only one app
can be associated with .py files. OTOH though, file associations can be
configured per-user IIRC, and assuming that is the case, we could avoid
my m
Mark Hammond gmail.com> writes:
> Sure, that would be awesome! I think that will mean your impl is fairly
> close to the first draft of the PEP I checked into HG, which is nice and
> still quite useful to use :)
My C implementation of the launcher is now available at
https://bitbucket.org/vi
Mark Hammond gmail.com> writes:
> The intention is that there only be a single launcher, as only one app
> can be associated with .py files. OTOH though, file associations can be
> configured per-user IIRC, and assuming that is the case, we could avoid
> my multiple-ini-file usecase above by
On 30/06/2011 10:09 PM, Vinay Sajip wrote:
There's a lot to like in the PEP, and I have some questions relating to the
latest version:
1. In the section on shebang line parsing, it says "If the command starts with
the definition of a customized command followed by a space character, the
customiz
On Thu, Jun 30, 2011 at 4:13 AM, Michael Foord
wrote:
> In the latest update Mark also addressed my main concern, making the
> launcher configurable so it can also be used by alternative implementations
> (particularly IronPython for Windows). I've copied Jeff Hardy and Dino
> (IronPython maintain
On 30 June 2011 12:13, Michael Foord wrote:
> I have that email (the update one from Mark not the silent nodding from Tim)
> still sitting in my inbox waiting for me to properly read through and
> comment on... Sorry for being useless, I'll try and move it up the priority
> list.
>
> I really like
Mark Hammond gmail.com> writes:
> Not yet - my last update of the PEP has made the existing reference
> implementation out-of-date, so I want to work on that before starting on
> the C version. However, seeing as my note about the most recent PEP
> update attracted zero comments, I admit I lo
On 30/06/2011 08:34, Tim Golden wrote:
On 30/06/2011 05:23, Mark Hammond wrote:
On 30/06/2011 3:00 AM, Vinay Sajip wrote:
PEP 397 (Python launcher for Windows) has a reference implementation
in Python.
Does anyone know of a C implementation, or is planning/working on one?
I realise
this is the
On 30/06/2011 05:23, Mark Hammond wrote:
On 30/06/2011 3:00 AM, Vinay Sajip wrote:
PEP 397 (Python launcher for Windows) has a reference implementation
in Python.
Does anyone know of a C implementation, or is planning/working on one?
I realise
this is the final objective, so such implementation
On 30/06/2011 3:00 AM, Vinay Sajip wrote:
PEP 397 (Python launcher for Windows) has a reference implementation in Python.
Does anyone know of a C implementation, or is planning/working on one? I realise
this is the final objective, so such implementation might be premature, but
perhaps someone ha
PEP 397 (Python launcher for Windows) has a reference implementation in Python.
Does anyone know of a C implementation, or is planning/working on one? I realise
this is the final objective, so such implementation might be premature, but
perhaps someone has been experimenting ...
Regards,
Vinay Sa
32 matches
Mail list logo
