On 4 January 2015 at 22:01, Paul Moore wrote:

On 3 January 2015 at 23:34, Steve Dower wrote: Also, how does the launcher py.exe fit into the picture? Is it still installed into the Windows directory? What about for a user install? Are Python scripts associated with the launcher, and if so, how does it pick up the version you selected as default?

(Sorry, that was more than one question :-))

The proposed installer changes look like a great improvement to me, but I think Paul's questions suggest that it will be useful to capture the many decisions involved in the redesign as a PEP. That serves a couple of useful purposes: 1. It helps guide the design itself, and ensure that the various usage scenarios (like build machines) are suitably covered. 2. When Python 3.5 is released, we can point readers of the What's New document to the PEP as a reference for the detailed decision making process that went into the changes that were made. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Thanks for all the comments. I've responded all at once, since I don't think any of the points raised are going to immediately turn into intense discussion. Feel free to trim the rest of the post if you want to respond to just one of the points. Donald Stufft wrote:

Does signing the .exe’s that ship with Python effect pip at all? I’m guessing not since pip.exe is actually a generic .exe that we use for any project and is shipped inside of the .whl files but I figured i’d ask.

Depending on the answer above, does it make sense to sign the generic .exe (does that even work if we rename it?) which will get used for anything that uses entry points on Windows?

Actually, I don't think the generic .exe can be signed, since embedding the script within the file will invalidate the certificate. It's better not to have the certificate at all in this case. If we were still using the separate pip-script.py file then we could sign it.

Is there any plan to backport this to 2.7 (presumably after some experience is had with it in 3.5)?

No. I'm very much in the "2.7 is finished" camp. Hitting rebuild every now and then for security updates is the extent of my interest (and in large part that's because if nobody is producing builds then I'll probably end up having to produce the builds to run on Azure anyway). Antione Pitrou wrote:

One comment: I would find it a bit confusing if the default install path changes when using the customized install. OTOH, maybe you can't choose another default there.

It's a tough one to choose, honestly. I really don't want separate "customize" buttons for per-user and all-user installs (too many up front decisions, especially for people who really should just choose the first option). My reasoning for having "C:\Python35" as the default there is to simplify the "just give me the old style install" case, but that may turn out to be a bad reason. I'm not sure yet. ChrisA wrote:

You talk of installing by default into Program Files, and having a separate per-user installation mode. How do these two installation targets interact? Suppose someone installs 3.5 globally, then installs 3.6 for self only? Or installs 3.5.1 for self only? I would normally expect a per-user installation to trump a global one, but this could make for a lovely dep-hell on a system that's used by one person, who then isn't sure what was installed as admin and what wasn't.

Yeah, it gets a little messy, especially if you keep adding all the Python versions to PATH (Windows will always put per-user PATH entries at the end). The py.exe launcher handles this best, and the system version will always be found first. As for versions, 3.5 vs 3.6 should be distinguished explicitly ("py -3.5" vs "py -3.6") and 3.5.0 vs 3.5.1 can only be installed at the same time if one is system-wide and the other is per-user. In this case, the per-user one will be used by py.exe, even if it is older than the system-wide one. Compared to the current situation, the per-user and all-user installs do not interfere as much.

(Also: I'm assuming that pip would require admin privs if Python is in Program Files, and won't require admins if it's per-user, right? Same as the Python installer itself?)

Correct. The pip guys are already looking into handling installs in this case since it matters on *nix, and having read-only Python installs on Windows will only make it more similar. It seems likely in this case that the user site-packages folder will be used if your user can't write to the shared site-packages. If you can write to it (either per-user install or running pip as admin) then you'll install to that folder. I am fully expecting to find the most issues in this area once we change the install location, and I don't think we can fix all these issues without actually releasing the change. So it's a bit of a risk, but one I feel is worth it. Of course, if the community and release manager disagree, I'll happily back it out and we can focus on testing it directly for a bit before inflicting it on our users. Glenn Linderman wrote:

But here's another idea: automatically keep all the .msi and .cab files used for the first installation of Python with it in the directory from which it runs (naming convention... prefix them all with python-3.5.0a1.<stuff>.(msi|cab) It is very likely that a reinstall will use the same components (if more are needed on a later install, add them to the directory also). And a good naming convention makes it obvious what to delete when done with the installer.

Unfortunately, I'm fairly restricted on naming convention. For some reason Windows Installer requires CAB files to be 8.3 names, where some of the 8 are reserved, so the names are pretty meaningless. However, Windows does automatically cache all the files (typically in C:\ProgramData\Package Cache) so that repairs and uninstalls don't need to redownload anything, and this cache is automatically managed to preserve disk space. If you add new features later then you won't have the files in the cache, which is about the only way that this doesn't already fit your suggestion. I think it's fairly unlikely that people will be surprised by this, though when the first complaints come it about it I'll happily reconsider.

And a related idea: on the first install page, have a check box "download all installation components", that would do that, even if they are not used, and even if either of the one-click installs are chosen.

Interesting idea, but I'm worried that people would think they need to click the box simply because it is there. I've seen the same thing happen in many other places, and I think this functionality is advanced enough that the people who need it know that they need it and will look for it. I could, however, add a help link to the first page of the installer, once there's somewhere for it to go.

And a related idea: for custom installs, record the choices made in a metadata file in that same directory, and after the first install, subsequent installs could have a 3rd single-click install: same custom install as last time. This would be kept in the directory with the installer, so could be applied to a zillion machines, and an install option /ditto would allow those choices from the command line. That way, the administrator could use the friendly interface to install the first machine, making the appropriate choices, and then just run "python-3.5.0a1.exe /ditto" on all the other zillion-1 machines, without needing to learn any other obscure command line parameters. I don't care how you spell /ditto, as long as there is documentation.

This is really interesting, and certainly possible. I'll keep it in mind as something to look into after alpha. (What may be easier is a message at the end showing the command line to use that will perform the same installation silently... hmm...)

Regarding /layout, to me, that name has no mnemonic meaning of "download all these installation components and save them". Documentation could provide that, of course, but choosing a name like /download might be nicer. Saving to the same directory as the installer lives in seems easier than needing to specify a directory... the documentation can warn that users of the option should put the web installer in the desired, shared or private, installation directory prior to running the option...

It's the standard option used by Burn (the install engine I'm using) - for example, the Visual Studio web installers will also respond to /layout - and it's probably from some internal Microsoft terminology. However, it's easy enough for me to add an alias. The installer also responds to "/?" and "/help" (IIRC, it may only be the first) to display all of its options, and I expect this will be the first thing people guess to try. Paul Moore wrote:

Overall, this looks good. One question - will it be possible to install both 32-bit and 64-bit Python on the same machine? Currently, you need a custom install to do this (as the default directory doesn't include the architecture) and IIRC there's some oddness around install order. It would be nice if installing both versions were a supported option, both for the "default" install and in custom installs.

Yes, the default install directories on the first page are different for 32-bit and 64-bit (either "Program Files [(x86)]" or "Python35[-32]"). The default value on the customize page is currently always C:\Python35, and so you'll need to change it if you're doing custom installs, but that's easy to add the "-32" by default. (I used a -32 suffix because it matches the py.exe option.)

Also, what happens now with setting PATH? Is Python (and the scripts directory) added to PATH by default? If so, what happens when you install 2 versions of Python?

Yes, and in general the later installed version will win and system-wide installs always beat per-user installs. As I mentioned above, using py.exe with a parameter or shebang line is the most reliable way to get the version you want.

In case it's not clear, I'm thinking of the impact on build machines, which often have multiple versions, in both 32- and 64-bit forms, installed simultaneously (but can also be used as a "normal" development machine, and for that purpose will want a selected Python version as the default one.

You should see my dev machines :) Most have 2.5, 2.6, 2.7 32-bit and 64-bit, 3.0, 3.1, 3.2, 3.3 32-bit and 64-bit, 3.4 32-bit and 64-bit, IronPython and often PyPy, Anaconda or Canopy. So I'm being fairly selfish when I try and make the multiple-versions scenario work better, but it will benefit everyone.

Also, how does the launcher py.exe fit into the picture? Is it still installed into the Windows directory? What about for a user install? Are Python scripts associated with the launcher, and if so, how does it pick up the version you selected as default?

py.exe is more important than ever. It's still installed into the Windows directory for all-user installs, and into the Python directory for just-for-me. It's installed in a way that will make upgrades more reliable (so if you install 3.6 and then 3.5, you'll keep the newer launcher) and all the file associations go straight to the launcher. The default Python for the launcher seems to be 2.7 if it's there and the latest version if not (though I could be wrong). Shebang lines are the best way to choose a specific version. Incidentally, whoever came up with the py.exe launcher deserves a medal. It's made dealing with multiple versions amazingly easy. Nick Coghlan wrote:

The proposed installer changes look like a great improvement to me, but I think Paul's questions suggest that it will be useful to capture the many decisions involved in the redesign as a PEP.

I was afraid someone would suggest this :) I certainly intend to document it thoroughly. One of my overarching goals is to make it really easy for the next person to take over producing builds, or for someone else to produce a signed release build if I'm unavailable. My intent was just to drop a text file in Tools/msi and some of the user-facing docs (like command-line options, best practices and rationale) into the main docs. If there's added value in a PEP, then I can do that too, though I would prefer the documentation for this to be more living than most PEPs are. Cheers, Steve

Chris Angelico wrote:

On Mon, Jan 5, 2015 at 9:56 AM, Steve Dower wrote:

...

(Windows will always put per-user PATH entries at the end). The py.exe launcher handles this best, and the system version will always be found first.

As for versions, 3.5 vs 3.6 should be distinguished explicitly ("py -3.5" vs "py -3.6") and 3.5.0 vs 3.5.1 can only be installed at the same time if one is system-wide and the other is per-user. In this case, the per-user one will be used by py.exe, even if it is older than the system-wide one.

Wait, what?</anna>

If I'm reading this correctly, PATH is set such that an all-users version trumps a self-only version, but when you use the py.exe launcher, it's the other way around? That seems extremely confusing. But if that's not a deliberate design decision and isn't enforced by external code, would it be possible to simply invert that for PATH, and have a per-user installation always be found ahead of a system-wide one? That would make reasonable sense, if it can be done.

Unfortunately, Windows enforces the PATH ordering. It constructs the PATH from two registry keys, one is the system-wide value (that requires administrative privileges to modify) and it is followed by the user's value (that does not require administrative privileges). This is probably for security reasons and can't be changed. PATH also suffers from including the most-recently installed Python version first, rather than the most recent version. Basically, py.exe gives the behaviour we want and PATH simply can't do it. I think this means the best way to make multiple versions work properly is to rename python.exe to python3.5.exe, then install the launcher as python.exe and python3.exe (with some logic to look at its own name) so it can resolve the right version. Maybe we can even extend the launcher to resolve launchers in Scripts (pip.exe, etc.) and have consistent rules there too? Or perhaps this is more trouble than it's worth, and we should let "py.exe" have a fixed set of rules and let PATH work as people have come to expect. Thoughts? Cheers, Steve

On 5 January 2015 at 01:20, Steve Dower wrote:

I think this means the best way to make multiple versions work properly is to rename python.exe to python3.5.exe, then install the launcher as python.exe and python3.exe (with some logic to look at its own name) so it can resolve the right version. Maybe we can even extend the launcher to resolve launchers in Scripts (pip.exe, etc.) and have consistent rules there too?

This was a big debate over on distutils-sig. I advocated "py -m pip" for portable use, but got basically nowhere. People want "pip" to work, for compatibility with Unix (and hence ease of documentation). If we can't get PATH sorted out, we need to do something about this, IMO. I don't know what (believe me, I tried to find a solution) unfortunately. Paul

On Tue, 6 Jan 2015 23:56:30 +1000 Nick Coghlan wrote:

On 5 January 2015 at 18:17, Paul Moore wrote:

...

On 5 January 2015 at 01:20, Steve Dower wrote:

...

I think this means the best way to make multiple versions work properly is to rename python.exe to python3.5.exe, then install the launcher as python.exe and python3.exe (with some logic to look at its own name) so it can resolve the right version. Maybe we can even extend the launcher to resolve launchers in Scripts (pip.exe, etc.) and have consistent rules there too?

This was a big debate over on distutils-sig. I advocated "py -m pip" for portable use, but got basically nowhere. People want "pip" to work, for compatibility with Unix (and hence ease of documentation).

"pip" is problematic on Linux as well (due to the pip/pip3 split at the system level). Hence this section in the stdlib docs: https://docs.python.org/3/installing/#work-with-multiple-versions-of-python-...

Why doesn't it recommend "pip3.4", etc. instead? Am I missing something about it? Thanks Antoine.

On 6 January 2015 at 13:56, Nick Coghlan wrote:

...

If we can't get PATH sorted out, we need to do something about this, IMO. I don't know what (believe me, I tried to find a solution) unfortunately.

I personally believe we should aim to make the "Windows" section in the above link universal (i.e. working across *nix, Windows, and virtual environments). That's the only one that can feasibly be made universal - all the other alternatives are already known to be incompatible with particular scenarios.

Making it the universally recommended approach is one thing. Getting people to actually work that way is another thing entirely :-( Also, the "Windows recommendation" (currently) doesn't work properly with virtualenv - there's no way to get py.exe to use "the currently active virtualenv" (i.e., the default version from PATH). It should be possible to fix this - the difficulty is likely to be designing a viable interface. As a first cut, I think py.exe should default to (in the following order): 1. The first version of Python on PATH that "looks like a virtualenv" (need to consider both venv and virtualenv styles). 2. The default version of Python set in the ini file. 3. The latest version of Python installed on the machine (no longer preferring Python 2 over Python 3!) A #! line in a script being run will override all of these, of course, as will explicit command line flags. Does this seem reasonable? I could work on a patch if it does. Paul

On 4 January 2015 at 22:56, Steve Dower wrote:

...

Also, what happens now with setting PATH? Is Python (and the scripts directory) added to PATH by default? If so, what happens when you install 2 versions of Python?

Yes, and in general the later installed version will win and system-wide installs always beat per-user installs. As I mentioned above, using py.exe with a parameter or shebang line is the most reliable way to get the version you want.

Hmm, that's unfortunate. Normally I leave "Add to PATH" off for all but one installation. I certainly don''t want all versions on there - I've had too many issues with running something like py.test and finding it's running Python 3.3 because I didn't install it into Python 3.4. I'm pretty sure we'll get bug reports "I installed Python 3.5.1 but I'm still getting Python 3.5" from the per-user behaviour. And saying "don't do that" isn't a fix, nor is blaming Microsoft, really. Unfortunately, I don't see a good solution here.

...

Also, how does the launcher py.exe fit into the picture? Is it still installed into the Windows directory? What about for a user install? Are Python scripts associated with the launcher, and if so, how does it pick up the version you selected as default?

py.exe is more important than ever. It's still installed into the Windows directory for all-user installs, and into the Python directory for just-for-me. It's installed in a way that will make upgrades more reliable (so if you install 3.6 and then 3.5, you'll keep the newer launcher) and all the file associations go straight to the launcher.

The biggest problem here is that py.exe doesn't help in the slightest with script wrappers like pip.exe, virtualenv.exe, py.test.exe, ipython.exe ... I've actually drifted away from using py.exe because of this. Having just the interpreter special cased isn't really good enough. (I know there's py -m pip, but it's not easy to get people to use this...) I think it's really important to only have one Python on your PATH, so just dumping everything there by default, particularly if user installs get pushed to the end and don't have precedence, is a bad experience.

The default Python for the launcher seems to be 2.7 if it's there and the latest version if not (though I could be wrong). Shebang lines are the best way to choose a specific version.

Yes, that's a very bad default IMO. It was probably reasonable at the time, but it should be fixed now - at least to a simple "the latest version". Getting a user who's just installed Python 3.5 (with a system Python 2.7 present) to edit an ini file in C:\Windows\System32 just to use his new version is *not* a good user experience. Paul

On 5 January 2015 at 08:40, Donald Stufft wrote:

...

The biggest problem here is that py.exe doesn't help in the slightest with script wrappers like pip.exe, virtualenv.exe, py.test.exe, ipython.exe ... I've actually drifted away from using py.exe because of this. Having just the interpreter special cased isn't really good enough. (I know there's py -m pip, but it's not easy to get people to use this...)

Won’t script wrappers use whatever version they were installs against? Or do you mean the “installed” version might be 3.5 for ``pip.exe`` even though there’s a 3.5.1 for ``pip.exe`` on the PATH?

What I mean is that if you have Python 3.4 and Python 3.5 installed, and pip.exe is in the Scripts directory of each, then which pip.exe you get (and hence which Python you install into) if you just type "pip install xxx" depends on your PATH. Steve is in essence saying that it's not possible to sanely manage PATH as part of the new installer, but that py.exe makes that unnecessary. My point is that while py handles the interpreter, it doesn't handle things like pip (unless we change the standard usage instructions to say "py -m pip" is the supported approach on Windows). Paul

On 05/01/2015 17:09, Steve Dower wrote:

Paul Moore wrote:

...

Steve is in essence saying that it's not possible to sanely manage PATH as part of the new installer, but that py.exe makes that unnecessary.

It's actually not possible to sanely manage PATH from any installer - it really needs to be handled by a user directly (though I can't ever bring myself to tell anyone to use the UI for it). The old installers were less susceptible because they didn't support per-user installs, but you'd still get the "last install Python wins" behaviour.

Something that's help keep me slightly sane is the Rapid Environment Editor http://www.rapidee.com/en/about. I'm sure there are plenty of other choices but it does what I need. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

Paul Moore wrote:

tl;dr We should have "Add this Python to PATH" as a user choice on the initial installer screen, applicable to whichever install type the user chooses. Details as to why are below.

I agree. I'll work this up before alpha 1. (FWIW, it defaults to unselected.) Displaying a warning about other Pythons already being on the path at this point is trickier, but I can probably figure something out.

For myself, I'll probably have to use the custom install to get the control I want. But that's suboptimal, as I probably *want* to use the new locations, and having to override the "Custom" default of C:\Python35 to specify "Program Files" is a nuisance. And I bet I'll install a 32-bit Python in "C:\Program Files" rather than "C:\Program Files (x86)" at least once, and probably more than once...

Inclined to agree, and it is possible to make the default on the customise page switch with the Install as Administrator checkbox until it's been manually edited. My main concern is people who want it the old way, but they may not actually exist. Perhaps making the old way trickier is the best way to flush them out sooner... Cheers, Steve

On 04/01/2015 22:56, Steve Dower wrote:

Paul Moore wrote:

...

Overall, this looks good. One question - will it be possible to install both 32-bit and 64-bit Python on the same machine? Currently, you need a custom install to do this (as the default directory doesn't include the architecture) and IIRC there's some oddness around install order. It would be nice if installing both versions were a supported option, both for the "default" install and in custom installs.

Yes, the default install directories on the first page are different for 32-bit and 64-bit (either "Program Files [(x86)]" or "Python35[-32]"). The default value on the customize page is currently always C:\Python35, and so you'll need to change it if you're doing custom installs, but that's easy to add the "-32" by default. (I used a -32 suffix because it matches the py.exe option.)

...

Also, what happens now with setting PATH? Is Python (and the scripts directory) added to PATH by default? If so, what happens when you install 2 versions of Python?

Yes, and in general the later installed version will win and system-wide installs always beat per-user installs. As I mentioned above, using py.exe with a parameter or shebang line is the most reliable way to get the version you want.

...

In case it's not clear, I'm thinking of the impact on build machines, which often have multiple versions, in both 32- and 64-bit forms, installed simultaneously (but can also be used as a "normal" development machine, and for that purpose will want a selected Python version as the default one.

You should see my dev machines :) Most have 2.5, 2.6, 2.7 32-bit and 64-bit, 3.0, 3.1, 3.2, 3.3 32-bit and 64-bit, 3.4 32-bit and 64-bit, IronPython and often PyPy, Anaconda or Canopy. So I'm being fairly selfish when I try and make the multiple-versions scenario work better, but it will benefit everyone.

...

Also, how does the launcher py.exe fit into the picture? Is it still installed into the Windows directory? What about for a user install? Are Python scripts associated with the launcher, and if so, how does it pick up the version you selected as default?

py.exe is more important than ever. It's still installed into the Windows directory for all-user installs, and into the Python directory for just-for-me. It's installed in a way that will make upgrades more reliable (so if you install 3.6 and then 3.5, you'll keep the newer launcher) and all the file associations go straight to the launcher.

The default Python for the launcher seems to be 2.7 if it's there and the latest version if not (though I could be wrong). Shebang lines are the best way to choose a specific version.

Incidentally, whoever came up with the py.exe launcher deserves a medal. It's made dealing with multiple versions amazingly easy.

If I'm reading this correctly it means that py.exe gets picked up from PATH so it could be 32 or 64 bit. Does this mean that the launcher could be or needs enhancing so 32 or 64 bit can be selected? I'm not sure if anything can be done about pyw.exe, perhaps you (plural) can throw some light on this for me. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

Ethan Furman:

On 01/04/2015 02:56 PM, Steve Dower wrote:

...

ChrisA wrote:

...

You talk of installing by default into Program Files, and having a separate per-user installation mode. How do these two installation targets interact? Suppose someone installs 3.5 globally, then installs 3.6 for self only? Or installs 3.5.1 for self only? I would normally expect a per-user installation to trump a global one, but this could make for a lovely dep-hell on a system that's used by one person, who then isn't sure what was installed as admin and what wasn't.

Yeah, it gets a little messy, especially if you keep adding all the Python versions to PATH (Windows will always put per-user PATH entries at the end). The py.exe launcher handles this best, and the system version will always be found first.

py.exe should *not* follow this behavior. User installs should be searched first, then system installs -- otherwise, what's the point in having a user-install? Filling up the gobs of disk-space we now have available?

Typo on my part. The py.exe launcher will always find the *user* install first. Searching PATH will always find the system version first.

Martin v. Löwis wrote:

Am 04.01.15 00:34, schrieb Steve Dower:

...

so I'm keen to hear whatever feedback people have.

One issue that I always wanted to address is patch releases. There are two aspects I dislike about the current implementation

a) an upgrade install first uninstalls the previous installation (removing all files), and then reinstalls all "new" files. In many patch releases, a lot of .py files remain unmodified, so it should speed up the upgrade if they would not need to be replaced. b) Installer supports patch files (.msp); I always wanted to provide them in the hope that this would reduce the download size. IIUC, it would require stable component IDs for components to be upgraded, which I could not manage to provide.

So, do you have any plans on dealing with a or b?

So the stable component IDs is dealt with - WiX will auto-generate them based on the relative install path of each file and a user-provided ID (to distinguish between the 32-bit and 64-bit installs, for example. This ID is currently generated from the hash of a user provided URI, which is also used to generate upgrade codes and a few fixed component IDs). Installing patches is something we can defer until 3.5.1, but I am interested in looking into it. My main concern is that it may hurt fresh installs (for example, 3.5.5 is actually 3.5.0.msi+.1.msp+.2.msp+.3.msp+.4.msp+.5.msp) and I'm not sure that true slipstreams are supported/recommended because it will affect future patches (different product codes, IIRC). So fresh installs of later versions may have a significantly increased download size. Because of the split into multiple MSIs, it's also possible to independently version some parts of it. I suspect this will only apply to the py.exe launcher, but if that is unchanged between 3.5.0 and 3.5.1 then we can leave its version at 3.5.0 and it won't be redownloaded/installed. Not a huge saving, but it's a possibility. I expect most MSIs will change in some way between versions, so an MSP is the only good way to improve upgrades (the main benefit of the MSI split here is we will always install the latest 32-bit launcher, and if you install 3.5 32-bit and 64-bit and eventually 3.6 32-bit and 64-bit you'll only have one launcher installed). Another possible problem is that MSI uses file version information to determine whether to update files. .py files don't have version information, so MSI to MSI updates are probably always going to replace everything - another reason why MSPs are the only good choice here. I'll chat to some of the guys who work on the Visual Studio installer, since it uses the same technology and is far more complex than Python's one. They may have some suggestions about how to approach this.

Other issues: - what MSI version do you require, and what is the minimum Windows version supporting that MSI version?

I need to double-check the support still, but the aim is to support back to Windows Vista, so I think that's Windows Installer 3.0. Of more concern is the installer EXE, which is going to require a minimum level C runtime that may not be available before we've installed...

- Since you are going to install into Program Files by default, I think the library should be precompiled by default - there is little chance that a regular user can save .pyc files when running Python. It might be possible to even include the pyc files in the distribution, if we can arrange to somehow support relative paths in co_filename.

Agreed. The library will be precompiled by default if you choose the All Users button on the front page, and you can control this independently through the customize option (to precompile Just for Me or install without precompiling).

Regards, Martin

Cheers, Steve