Create python.portable package

[alexchandel]

The Python package is a good candidate for installation into %ChocolateyInstall%, instead of the current Get-BinRoot. It's essentially self-contained and it only places two binaries in the PATH, python.exe and pythonw.exe, both of which can be shimmed into %ChocolateyInstall%\bin. This also has the effect of consolidating one more directory in the PATH into %ChocolateyInstall%\bin.

[ferventcoder]

This would make a good candidate for a python.portable package.

[alexchandel]

Sounds like a plan. I only found MSI's for Windows in their releases, so would we use an administrative install? Or is there a zipfile for Python 3.4.3 floating around somewhere?

[TomOne]

This would make a good candidate for a python.portable package.

I think it would actually be better to just change the install location to $PSScriptRoot as binRoot is deprecated anyways. No need for a portable package as that would in fact be a duplicate of the existing python packages.

I’d gladly accept a PR for that.

[ferventcoder]

binRoot is deprecated anyways

Not yet it isn't. The message is that we will be deprecating it in the future. It's an early heads up, not a warning that it is deprecated.

[ferventcoder]

$PSScriptRoot is not available for POSH v2. That's why the longer method of getting the script root is recommended.

[ferventcoder]

LessMSI is a great way to install portables from an MSI. Check out the latest 7zip portable package - https://chocolatey.org/packages/7zip.commandline#files

[TomOne]

$PSScriptRoot is not available for POSH v2.

I know. I only wrote it here because it’s shorter. 😄

binRoot is deprecated anyways

Not yet it isn't.

Sure, but since Chocolatey eventually got rid of versioned folders there’s no reason left to stick with binRoot.

[ferventcoder]

Sure, but since Chocolatey eventually got rid of versioned folders there’s no reason left to stick with binRoot.

It's growing up haha

[ferventcoder]

I was thinking more for the idea that python is an installed application, not a portable. It sets things like path and the like. However putting it all in the package folder is also fine.

EDIT FOR CLARIFICATION: Only a portable should go into the package folder. If it is a native installer, it should almost _never_ be installed to the package folder. It can potentially cause too many issues.

[alexchandel]

I'd prefer not to have any Python in my path at all, tbh. I don't like the idea of packages I intend to use from the command line messing with my path and dumping bloat in the registry.

LessMSI seems like the optimal solution for unarchiving the MSI directly into %ChocolateyInstall%\bin. It doesn't require running as Administrator, unlike the crippled "administrative install", and it doesn't modify the registry. I'd be interested in seeing it applied to other packages that currently install MSIs...

[ferventcoder]

To be clear, these would be new packages with the name *.portable. Not everyone thinks the same way as you and I.

[alexchandel]

I feared as much, but a portable python package would still be pretty nice ;)

Does this work?

$packageName = 'python.portable'
$toolsDir = $(Split-Path -parent $MyInvocation.MyCommand.Definition)
$installDir = Join-Path "$toolsDir" 'python'
$fileName = "$($packageName).msi"
$file = Join-Path "$toolsDir" "$fileName"

$url = 'https://www.python.org/ftp/python/3.4.3/python-3.4.3.msi'
$url64 = 'https://www.python.org/ftp/python/3.4.3/python-3.4.3.amd64.msi'

Get-ChocolateyWebFile "$packageName" "$file" "$url" "$url64"

pushd "$toolsDir"
# the trailing backslash is required!
&lessmsi x "$fileName" "$installDir\"
popd

Not 100% sure about the $installDir, and there are a bunch of tools named like ./Lib/distutils/command/wininst-10.0.exe that should be skipped by shimgen, as well as basically everything in ./Lib/site-packages/.

[ferventcoder]

That's pretty close, one can also write out .ignore files on the fly that don't apply. I've built a package or two that does this - see sysinternals.

[pyhedgehog]

As a result of this "fix" I've got error: "The fully qualified file name must be less than 260 characters". Old c:\tools\python3 was pretty good.

C:\>cup -y python3
Upgrading the following packages:
python3
By upgrading you accept licenses for the packages.
You have python3 v3.4.3.20150501 installed. Version 3.5.0.20151010 is available based on your source(s).

python3 v3.5.0.20151010
 Downloading python3 64 bit
   from 'https://www.python.org/ftp/python/3.5.0/python-3.5.0-amd64.exe'
 Installing python3...
 python3 has been installed.
 Get-ChildItem : The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
 At C:\ProgramData\chocolatey\lib\python3\tools\chocolateyInstall.ps1:24 char:14
 + Get-ChildItem <<<<  -Path $destinationFolder -Recurse | Where {
     + CategoryInfo          : ReadError: (C:\ProgramData\...am\node_modules:String) [Get-ChildItem], PathTooLongException
     + FullyQualifiedErrorId : DirIOError,Microsoft.PowerShell.Commands.GetChildItemCommand
 Get-ChildItem : The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
 At C:\ProgramData\chocolatey\lib\python3\tools\chocolateyInstall.ps1:24 char:14
 + Get-ChildItem <<<<  -Path $destinationFolder -Recurse | Where {
     + CategoryInfo          : ReadError: (C:\ProgramData\...am\node_modules:String) [Get-ChildItem], PathTooLongException
     + FullyQualifiedErrorId : DirIOError,Microsoft.PowerShell.Commands.GetChildItemCommand
The upgrade of python3 was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\python3\tools\chocolateyInstall.ps1'.
 See log for details.

Chocolatey upgraded 0/1 package(s). 1 package(s) failed.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
Failures:
 - python3

[pyhedgehog]

On second review node_modules in error message direct us to installed nodist package...
This still is bug in python3 package - "bad" files in other directories should not crash package installation.
Right now workaround is carefully crafted sequence of npm dedup commands.

[dtgm]

Get-ChildItem : The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
At C:\ProgramData\chocolatey\lib\python3\tools\chocolateyInstall.ps1:24 char:14

• Get-ChildItem <<<< -Path $destinationFolder -Recurse | Where {
  • CategoryInfo : ReadError: (C:\ProgramData...am\node_modules:String) [Get-ChildItem], PathTooLongException
  • FullyQualifiedErrorId : DirIOError,Microsoft.PowerShell.Commands.GetChildItemCommand

It's because there is an undefined variable $destinationFolder in the script when it is generating a list of files for shimgen.exe to ignore. The variable defaults to $PWD and traverses that path recursively.

This error has been present since version 3.5.0

[gep13]

@dtgm would you be in a position to submit a PR to correct this? I would very much appreciate it 😸

[ferventcoder]

Related to #106.

[gheoan]

A python.portable package would be useful.

[dragon788]

I think per #106 (comment) maybe this one should be closed unless somebody is avoiding the native installer and just copying in the python binaries. A thing to note is you also probably REALLY want the pip.exe shimmed if you do this, otherwise you'll have a lot of pain adding new packages, and Python/pip are going to be looking for site-packages directories in a structure that it won't find if not using the native installer.

[majkinetor]

Yeah, people want c:/PythonXX and with multiple versions.