Pik should be usable without administrator rights

[voxik]

Pik requires administrator rights for some actions, that is not nice:

C:\>pik package 7zip install
INFO: Downloading:  http://downloads.sourceforge.net/sevenzip/7za920.zip
      to:  C:\Users\vita\.pik\downloads\7za920.zip

7za920.zip: 100% |ooooooooooooooooooooooooooooo| 375.8KB/375.8KB Time: 00:00:00

There was an error.
 Error: Permission denied - C:\Program Files (x86)\pik/7za.exe

  in: zip/zip.rb:834:in `initialize'
  in: zip/zip.rb:834:in `open'
  in: zip/zip.rb:834:in `write_file'
  in: zip/zip.rb:465:in `extract'
  in: zip/zip.rb:1469:in `extract'
  in: pik/contrib/unzip.rb:9:in `fake_unzip'
  in: zip/zip.rb:1122:in `each'
  in: zip/zip.rb:1122:in `each'
  in: zip/zip.rb:1265:in `each'
  in: zip/zip.rb:1402:in `foreach'
  in: zip/zip.rb:1381:in `open'
  in: zip/zip.rb:1400:in `foreach'
  in: pik/contrib/unzip.rb:7:in `fake_unzip'
  in: zip/zip.rb:1381:in `open'
  in: pik/contrib/unzip.rb:6:in `fake_unzip'
  in: pik/commands/package_command.rb:57:in `sevenzip'
  in: pik/commands/package_command.rb:14:in `execute'
  in: pik_runner:27

Se also issue #87

[vertiginous]

I'm sort of stuck here.

I'd prefer people didn't install to %PROGRAMFILES% in the first place. Windows 7 doesn't allow regular users (even users with admin privileges) to write files there. There is nothing I can do about that. If you do want to install there, I did provide a method of installing executables to other locations, or you can run the command as the administrator, using the runas command.

Files like sqlite.dll need to be in the path in order to work with the sqlite3 gem. That's why it defaults to install to the directory pik is installed to. I don't like assuming that pik is in the path, so I gave the user the option to install these packages to other locations if they like.

pik package sqlite install C:\bin

I do think I need to document this better, but frankly I'm just going to discourage people from installing to %PROGRAMFILES%. Plenty of other applications make the same recommendation, so it's not unheard of.

[voxik]

well, as an administrator of my system, I see no problem with installing pik under %PROGRAMFILES% and that is for installed program the best place. I works just fine from there. The only issue is that you expect that downloaded 7z should be placed next to the executable, but there is no reason.

Pik already have directory where it can write and knows how to find it. This is ~/.pik directory. So when pik needs 7z and it is not in your path, I see no reason why it should not go into the ~/.pik instead of somewhere into program files

So in this case, you need administrator privilegs just to install Pik into program files and not anymore

[voxik]

BTW, plenty of other aplications install into the other folders, but it is wrong decision ... they have always different reasons and the one most common is that the cant handle spaces ... WTF? ... spaces are allowed in filenames on windows for 15 years, from Win95 as far as I remember ...

[vertiginous]

So you're backing up the claim that all applications should be installed to %PROGRAMFILES% by telling me pik should install the 7Z executable on your machine outside of %PROGRAMFILES%?

This is not an issue of spaces in the path, it's an issue of Windows UAC. I've given you two workarounds. If you're unhappy with both of those, feel free to fork the project and send me a pull request.

[voxik]

So why do you install Rubies into ~/.pik then? You should install them by the pik. Why should be 7z exception?

And again, you will be on safe side when you explicitly install 7z somewhere you know where you find it and do not relay on path, because you will avoid potential clash with my "super script" which is named by coincidence 7z.

You cannot force user to install Pik where you like, but you can avoid later problems.

[voxik]

Also remember this:

0.2.8 / 2010-06-22

\ BACKWARD COMPATIBILITY CHANGE pik will now install new rubies to %USERPROFILE%\rubies\, instead of %PIK_BIN%\pik\ this was necessary to all for installation into %PROGRAMFILES% dir. If you'd like to keep the old path, run:

pik config install_dir=C:\path\to\pik **

• fixed bug in 'devkit update' - gcc.bat file was writing to/overwriting sh.bat
• added support for powershell
• added support for Git Bash
• it is now possible to install pik to %PROGRAMFILES%

You are now again step back, so it is nothing new

[vertiginous]

I've been thinking a lot about this. I think installing 7zip to ~/.pik is an acceptable workaround. I can do that for 7zip, and probably for some other packages.

However, it doesn't make sense to install all of the other packages there. The devkit will have problems with any path with spaces (XP users have Documents and Settings). The sqlite dll needs to be installed somewhere that is in the path. All of these are special cases that I should probably check for and warn the user of, if they try to do something that isn't going to work.

Another problem comes up with 'pik update'. It will fail if the user installed to %PROGRAMFILES%. After some research, I think the appropriate thing to do is abort with an error message similar to:

"Access Denied. Administrator permissions are needed to use the selected options. Use an administrator command prompt to complete these tasks."

http://msdn.microsoft.com/en-us/library/bb756922.aspx

[voxik]

You are right with the DevKit and XP. However DevKit and Rubies were installed under user profile with Pik 0.2.8 (at leas I don't remember any special action) ... It might be good idea to check path for spaces when installing DevKit. And better Idea is to remove this issues with spaces if they exist in DevKit (I was always optimist ;)).

Actually, I am not big fan o "pik update". I would prefer the reinstallation with installer in this case, since there could be some leftovers after uninstalling updated pik. However running "pik update" as an administrator is perfectly acceptable