PATH Handling

[lvillani]

Provide a new catalog entry so that just-install can manage the System path by appending entries to an AutoRun script for cmd.exe.

Do not edit the PATH environment variable as set in the Registry, just-install should not fiddle by itself with these settings. Leave the responsibility up to the package itself.

Reference: http://technet.microsoft.com/en-us/library/cc779439(v=ws.10).aspx

[tim-lebedkov]

FYI:
Here is what is considered as ideal in handling PATH in Npackd:
https://code.google.com/p/windows-package-manager/wiki/IdealPackage#PATH

I plan to use EXE Proxy instead of modifying PATH in the future:
https://npackd.appspot.com/p/exeproxy/0.1

The exe files will be created in this directory and will point the the real binaries:
C:\ProgramData\Npackd\Commands

[lvillani]

How does exeproxy compare to creating a batch file "shim" like those created by Chocolatey?

[tim-lebedkov]

AFAIK the newer versions of Chocolatey also use .exe shims. See shimgen.exe at https://github.com/chocolatey/chocolatey/tree/master/src/tools
It is unfortunately not an open source software.

The main disadvantage of .bat files is that they do not work if user enters "abc.exe" in the command line.

[tim-lebedkov]

BTW, congrats to a successful rewrite. A really rare event. Strangely I also started Npackd in Java, but rewrote it in C++ later and also tested Lazarus and Go lately.

[lvillani]

On 12 Aug 2014, at 16:55, tim-lebedkov notifications@github.com wrote:

AFAIK the newer versions of Chocolatey also use .exe shims. See shimgen.exe at https://github.com/chocolatey/chocolatey/tree/master/src/tools
It is unfortunately not an open source software.

Yeah, I tried to peek into Chocolatey’s source code to see how they do this and found a bunch of .exe(s).

The main disadvantage of .bat files is that they do not work if user enters "abc.exe" in the command line.

The main advantage is that I wouldn't depend on an external tool for this job.

I guess that for a first implementation I can just go and write .cmd/.bat shims, then switch to exeproxy if/when enough users complain about stuff being broken :)

[lvillani]

On 12 Aug 2014, at 16:59, tim-lebedkov notifications@github.com wrote:

BTW, congrats to a successful rewrite. A really rare event. Strangely I also started Npackd in Java, but rewrote it in C++ later and also tested Lazarus and Go lately.

Thanks! I mainly rewrote it because, on some machines, the executable generated by PyInstaller wasn’t sufficiently self-contanined (mainly thanks to Microsoft’s mess around the C runtime and WinSxS). Also, some anti-virus programs incorrectly flagged the executable (probably because of the odd behaviour of PyInstaller’s self-extracting archive/boot-loader) and I wanted to get rid of that problem, too.

I’m more inclined towards Rust as my next systems programming language of choice. At the time of writing, however, it is still under heavy development (though they are rapidly approaching a 1.0 release). Because of this, I decided to give Go a shot. All in all, it was a good decision. It has huge momentum and there are already lots of libraries around. The language in itself is “meh”, but tooling and libraries are great.

[lvillani]

Note to self: after a bit of thinking I decided to directly go with exeproxy. It will be provided as an installable package with its own entry in the registry and it will be used only when detected. The path where shims are created will be hard-coded in the name of "zero configuration", something like %SystemDrive%\just-install.

Due to this, I'm also investigating the possibility to change the way just-install is installed, moving away from the "copy myself to %WinDir% on first start" (see #45).

[tim-lebedkov]

as far as I see you have replaced exe-proxy by mklink. This would not work if the .exe uses .dlls from the directory where the .exe is installed. BTW, there was a bug in exe-proxy 0.1. Here is the updated version: http://npackd.appspot.com/p/exeproxy/0.2

[lvillani]

Right, that's why I didn't close this bug, I wanted to see how far I could go with mklink (which appears to work for my use case -- AdvancedInstaller, git, mercurial and so on). I'll try again with Exeproxy 0.2 later this week.

[lvillani]

exeproxy 0.2 looks fine. I'll do some further testing this week.

[tim-lebedkov]

thanks. Just post here if something does not work.

[lvillani]

Will be included in 2.3.0 to be released today. Closing.