improve the OS-X packages #2741
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#2741
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 runtahoe
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 anEnable Terminal Usage..
menu item (which writes things into/usr/local/bin
): maybe we could change the stubtahoe.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 totahoe start
,tahoe stop
, andtahoe 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.
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).