improve the OS-X packages #2741

Open
opened 2016-03-16 08:32:23 +00:00 by warner · 1 comment

Our buildbot currently creates OS-X packages (.pkg installers) with each commit, but they're a bit disappointing. They install an icon to /Applications/tahoe.app, but clicking that icon only brings up a dialog box that tells you to run tahoe in a Terminal window. There is a /Applications/tahoe.app/bin/tahoe which can be run, but it's not in $PATH anywhere, so you have to type a lot or symlink it into a more useful directory (edit: and it will be on the $PATH of new shells if your .bashrc doesn't override it).

(also, the packages are completely broken after the tox/pip/virtualenv switchover, but I'm hoping to fix that before the release).

The baseline fix would be to get bin/tahoe into a normal $PATH somehow. I don't know if applications packages can do that (CLI tools aren't a normal thing for .apps to offer). I've seen GitX and some XCode tools offer an Enable Terminal Usage.. menu item (which writes things into /usr/local/bin): maybe we could change the stub tahoe.app launcher to offer a similar option.

The longer-term fix would be to add a real launcher application. I don't think we have to go so far as to write a fully-native OS-X frontend for Tahoe. But I'd like something that behaves like the CouchDB launcher: a "Statusbar app", which adds a single icon to the top-of-the-screen menu (over by the wifi and clock icons). This icon leads to a drop-down menu with a few options: "Launch Daemon", "Open Web", and "Quit".

It would probably need a "Create Client" option which leads to a short dialog (maybe driven by a web page) that lets you paste in the introducer.furl and pick a client nickname, then creates your ~/.tahoe/ directory. Then start/stop/open map directly to tahoe start, tahoe stop, and tahoe webopen. Maybe throw in a rootcap/alias.

RUMPS is a library that would probably make this easier.

Eventually it would be nice to have a proper setup application, so getting started with Tahoe felt nicer and more polished.

Our buildbot currently creates OS-X packages (.pkg installers) with each commit, but they're a bit disappointing. They install an icon to `/Applications/tahoe.app`, but clicking that icon only brings up a dialog box that tells you to run `tahoe` in a Terminal window. There is a `/Applications/tahoe.app/bin/tahoe` which can be run, ~~but it's not in $PATH anywhere, so you have to type a lot or symlink it into a more useful directory~~ (edit: and it will be on the $PATH of new shells if your .bashrc doesn't override it). ~~(also, the packages are completely broken after the tox/pip/virtualenv switchover, but I'm hoping to fix that before the release).~~ The baseline fix would be to get `bin/tahoe` into a normal $PATH somehow. I don't know if applications packages can do that (CLI tools aren't a normal thing for .apps to offer). I've seen GitX and some XCode tools offer an `Enable Terminal Usage..` menu item (which writes things into `/usr/local/bin`): maybe we could change the stub `tahoe.app` launcher to offer a similar option. The longer-term fix would be to add a real launcher application. I don't think we have to go so far as to write a fully-native OS-X frontend for Tahoe. But I'd like something that behaves like the CouchDB launcher: a "Statusbar app", which adds a single icon to the top-of-the-screen menu (over by the wifi and clock icons). This icon leads to a drop-down menu with a few options: "Launch Daemon", "Open Web", and "Quit". It would probably need a "Create Client" option which leads to a short dialog (maybe driven by a web page) that lets you paste in the introducer.furl and pick a client nickname, then creates your `~/.tahoe/` directory. Then start/stop/open map directly to `tahoe start`, `tahoe stop`, and `tahoe webopen`. Maybe throw in a rootcap/alias. [RUMPS](https://github.com/jaredks/rumps) is a library that would probably make this easier. Eventually it would be nice to have a proper setup application, so getting started with Tahoe felt nicer and more polished.
warner added the
packaging
normal
task
1.10.2
labels 2016-03-16 08:32:23 +00:00
warner added this to the undecided milestone 2016-03-16 08:32:23 +00:00
Author

I fixed the installer: the current one should be functional.

I see that the installer adds /Applications/tahoe.app/bin/ to /etc/paths.d/tahoe, and if I start a new shell, that shows up in $PATH. (I didn't see this earlier because my .bashrc overrode $PATH entirely).

I fixed the installer: the current one should be functional. I see that the installer adds `/Applications/tahoe.app/bin/` to `/etc/paths.d/tahoe`, and if I start a new shell, that shows up in $PATH. (I didn't see this earlier because my .bashrc overrode $PATH entirely).
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#2741
No description provided.