Closed TheCakeIsNaOH closed 3 years ago
Thanks for detailed report.
How would calls to choco.exe work on linux side (packing and pushing) ?
Choco can be installed and run on Mono, and a wrapper script can be put on the $path.
Stick something like this in /usr/local/bin/choco.exe
and in /usr/local/bin/choco
#!/bin/bash
mono /opt/chocolatey/console/choco.exe "$@" --allow-unofficial
This will have to be done manually by the person running AU, as will installation of any other dependencies (7z, etc).
I have a branch here with changes: https://github.com/TheCakeIsNaOH/au/commits/linux-support It's not PR ready (yet), but it's a start.
Additional considerations on the package maintainer end:
update_all.ps1
script, and possibly other custom scripts to use a platform-agnostic directory separator. Get-RemoteChecksum
instead if needed.au_SearchReplace
and the filename of the file have the same casingInstall-Module AU
works no problem, so that should be a viable install method later, and also I probably should develop a linux install script, or make the current one work with linux.I would like it on linux (or everywhere) to not depend on choco (as it depends on mono and it depends on ....) to pack/push. Push could be done easily via API but not sure what could be used as choco pack
on linux without choco
Maybe somebody from choco team could help with info in that regard (@ferventcoder @gep13). Maybe something like this? This would allow you to do entire AU stuff on Linux as on Windows. The only thing missing would be local testing but that is not particular downside given that packages are for Windows.
In the 12 days of Chocolatey, @ferventcoder did say that moving to dotnet core was a major item on the want-to-do list for 2021. https://youtu.be/ren6uzV5ZHc?t=1624
With that, choco.exe
should run with dotnet installed. Alternatively, chocolatey.lib
should also work, and that is something that could be bundled with AU. This would also allow the pack validation to work, once it is added to choco.
I don't really like the idea of using dotnet pack
. It requires creating a .csproj
file, it vomits out a bunch of auto-created files, and it complains that a number of things are deprecated, for example, the licenseUrl
, and the iconUrl
. Though it does work, at least as far as I can tell.
In regard to deprecating automatic checksumming, even if it was removed completely, it's not like people couldn't use an old version of AU. Both the chocolatey package and the PowerShell gallery module are self-contained, so old versions will work.
Maybe throw on non-windows, and print a warning on Windows. Then in a year or whatever, remove it completely.
The only thing missing would be local testing but that is not particular downside given that packages are for Windows.
Virtualbox and Vagrant are available on Linux, so hopefully, it should not be too hard to get the test environment working there.
In the 12 days of Chocolatey, @ferventcoder did say that moving to dotnet core was a major item on the want-to-do list for 2021. https://youtu.be/ren6uzV5ZHc?t=1624
Sure, lets wait on that then I guess its not a matter of want but matter of must for choco.
Virtualbox and Vagrant are available on Linux, so hopefully, it should not be too hard to get the test environment working there.
I am thinking on deprecating that too in Test-Package and go with Windows Sandbox as vbox with vagrant is enormous pain in the ass. Not that it would work as is on Linux too.
Automatic checksumming probably won't work and would be really hard to get working. But always using -ChecksumFor none and Get-RemoteChecksum is pretty easy to do on the maintainer end, so IMO this should be the required way to do it on Linux.
It could also be added in $PROFILE: $au_ChecksumFor = 'none'
. It can't override what is in update.ps1 but it wont be default any more.
I guess its not a matter of want but matter of must for choco.
It's on the must-do eventually, but they seem to get really touchy talking about dates, and I just wanted to head that off at the pass.
vbox with vagrant is enormous pain in the ass.
True.
I am thinking on deprecating that too in Test-Package and go with Windows Sandbox
There are definite merits to that idea. Not having to download and keep a copy of the 4GB vm image would be a plus.
Windows sandbox does conflict with running VirtualBox due to Hyper-V issues.
At some point, I could also work on getting a test environment like thing setup for KVM on linux, probably with one old image (like the current test env), and one up to date one (latest win 10). It's not like it's that much code to write.
It could also be added in $PROFILE: $au_ChecksumFor = 'none'
I'm not really a fan of that for consistency purposes, like running AU in a CI environment or similar. Although, for something like that, that can just be added to the CI build config, or probably in your update_all.ps1
would work fine as well for a CI environment.
but they seem to get really touchy talking about dates
Yeah, I know. They are very touchy in general: ¯\_(ツ)_/¯
Windows sandbox does conflict with running VirtualBox due to Hyper-V issues.
That was fixed. However, sandbox usually starts in seconds. On the negative side, you can't snapshot state but I guess its not a big problem in our case.
That was fixed.
It has never worked for me. When I have tried that VirtualBox never won't boot windows VMs anymore. They just spin the dots endlessly during boot or bluescreen.
Maybe I should try again, they might have fixed my issues more recently.
I didn't try it either.
It seems to work on Linux now (at least update functionality does), but one issue I have encountered is lack of support for case-sensitive file systems. In my package, au_SearchReplace searches for patterns in chocolateyInstall.ps1, but the actual file name is lowercase. That results in a failure, obviously.
au_SearchReplace searches for patterns in chocolateyInstall.ps1, but the actual file name is lowercase.
No it doesn't. I uses file names you give it to.
Automatic checksum has hardcoded this kind of name but you shouldn't use it anyway.
It also looks like this one can be closed, @TheCakeIsNaOH ?
I'd say it probably could be. Any further things could get their own issue if they come up.
It would be good to document the remaining possible issues and things to be aware of in the wiki, e.g. like the nuspec files element, and not using the automatic check summing.
With regards to the au_SearchReplace
, @niks255 and I where talking and perhaps we could do something like:
$filename = (Get-Childitem -Path $filename).fullname
which I think would allow it to be case-insensitive.
No it doesn't. I uses file names you give it to.
That's the point. I pass chocolateyInstall.ps1, but actual file name is chocolateyinstall.ps1, and that is perfectly acceptable on Windows, but not on Linux.
With regards to the
au_SearchReplace
, @niks255 and I where talking and perhaps we could do something like:
$filename = (Get-Childitem -Path $filename).fullname
which I think would allow it to be case-insensitive.
Yeah, just run Get-ChildItem on a directory that contains a file and then do Where-Object {$_.Name -Like "file name without path"}).BaseName
The filename problem is not something AU should be concerned with and is trivial to solve in multiple ways.
I will close this then when I add Linux notes in docs.
Thx @TheCakeIsNaOH for making this work.
Here is the list of stuff to put in the Linux notes that I know of;
au_searchreplace
filenames are the correct case (fix on user end)I am just beginning to use this on Linux and the progress is incredible! @majkinetor @TheCakeIsNaOH Thanks for your efforts!
So, I'd like to be able to run AU on Linux for a couple of reasons, and it seems like at least a subset of AU features are almost ready to go. Here is a list of current blocking problems that I have found:
mkdir
,rm
,gc
,pushd
,popd
,ls
,set
,cp
,tee
, andsort
. The solution is fairly simple; replace these (or all) aliases with the full versions. (#235)[enum]::GetValues('Net.SecurityProtocolType')
says thatssl3
is supported, but when I actually try to set it, it says that it is not supported. Again should be a simple fix to selecttls
or higher when running on non-windows. (#236)AUPackage
class definition,NuspecPath
is defined with a hardcoded backslash. Needs use[IO.Path]::DirectorySeparatorChar
instead. There are probably other spots with a hardcoded backslash that would need to be switched to a platform-independent method, i.e.Join-Path
or whatever. Edit:get-remotefiles
also needs changes for this, and some of the plugins almost certainly do as well. (#237)-ChecksumFor none
andGet-RemoteChecksum
is pretty easy to do on the maintainer end, so IMO this should be the required way to do it on Linux.choco pack
fails if the nupkg already exists. https://github.com/chocolatey/choco/issues/2076There are probably some things lurking that I missed, but those should get at least a minimum amount of functionality.