search

LeastAuthority / leastauthority.com

Least Authority S4
https://leastauthority.com/
Other
14 stars 18 forks source link

It may be difficult for OS X users to use S4 #685

Open exarkun opened 6 years ago

exarkun commented 6 years ago

A customer on OS X recently detailed their experience for us:

I first tried installing using: https://github.com/tahoe-lafs/tahoe-lafs/blob/master/docs/OS-X.rst

As it was the first thing I came across for mac in the readme. It does not properly simlink to use/local/bin and when I tried to do it manually there was some sort of package error when invoking the command.

The pips install was much easier.

I would recommend:

  • Removing the hyperlink on 'mac' in following line from the github readme: Mac and Windows installers are in development. That wasted half an hour of my day.

  • Seems like these tickets could be closed and development foccuses elsewhere now that gridsyn exists?

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2741

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/182

exarkun commented 6 years ago

We should take a closer look at the OS X installation experience for Tahoe-LAFS and determine if there's anything we can do to make it better.

This requires access to an OS X machine, of course, which I don't presently have so I can't easily do much to move this forward. (There are some cloud OS X services which I think LeastAuthority may have used in the past; that might be one way forward, but they're a lot more hassle (read: "slow") than a true, local OS X machine.)

crwood commented 6 years ago

FWIW, in my experience, the tahoe ".pkg" installer is indeed pretty broken and I agree with the implication that it shouldn't be used/recommended at all. Last I tried it (which, granted, was a couple of years ago -- but I don't think it has changed since) there were two big issues that stuck out for me:

1) It required administrator access to run (presumably because it tries to edit the $PATH at the system level) which is arguably unnecessary and violates the POLA.

2) The resultant installed application didn't actually work in the ways that OS X users expect. To be sure, it created "tahoe.app" file (which, according to OS X guidelines, suggests a graphical application that OS X users can click on to run) when, in actuality, it was merely a bundle containing the standard tahoe command line program (requiring users to use the terminal to run/interact with it).

That said, it is arguably safe, easier, and less confusing for OS X users to just follow the standard python steps/procedure (i.e., of pip install tahoe-lafs into a virtualenv or whatever) to get tahoe up and running.

As for trying to make things better, two suggestions would be 1) to contribute/maintain an upstream homebrew formula for Tahoe-LAFS (since this now seems to be most popular OS X package-manager for CLI/unix-y programs) or 2) provide standalone tahoe-lafs binaries (using, e.g, PyInstaller) for users who want to use tahoe via the CLI but who don't want to have to jump through the extra hoops of installing python and a compiler, etc. (note, my PR for this was merged some time ago, but it still needs to be hooked into the tahoe-lafs.org buildbot scripts/deployment pipeline).