build a .pkg installer for Mac OS X 10.9 Mavericks (intel-x86-64) #182
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
6 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#182
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?
My Mom wants to see some home movies of my children playing in the back yard. Even though our source:docs/quickstart.rst is very well written, it is still far beyond her ken to build Tahoe from source. How could she get Tahoe installed on her home computer, which is a PowerPC G5 running Mac OS 10.3.9?
One way is that I could upload a binary .egg and instruct her in how to install Python 2.5.1 and easy_install and then how to run "easy_install allmydata-tahoe". However, the dependent libraries like Nevow and Twisted and so forth wouldn't get automatically installed by easy_install so that wouldn't quite work.
Another way is that I could build binary .egg packages of all of our dependent libraries and host them somewhere or bundle them into the tahoe binary .egg.
Another way is that we could use the "py2app" feature to build an installer than works on Mac OS 10.
The py2app approach still requires that we bundle binaries of all of our dependent libraries.
So perhaps a next-step on this is to experiment with making a complete bundle of Tahoe and all dependencies. :-) I did that for Zfone and then used py2app to build a Mac .app of the result.
The py2app approach would require those dependent libraries to be present on the package-builder's machine, but the resulting package would be completely standalone, right?
I've started playing with py2app and have run into some problems (it seems to refuse to include foolscap in the bundle, despite being explicitly imported by the main entry-point script, even though it includes zfec and twisted just fine). But overall I think it will work.
So my main question is: what exactly should this packaged application look like?
One possibility:
is created
page
in a way that allows it to be cut-and-pasted into another application
thoughts?
Right.
A Mac OS X idiom which I love is that installing is merely dragging and dropping (i.e. copying or moving) the Thingie.app into your filesystem. This pattern abjures running an "installer" (I'm not sure if that's related to an "Assistant") at install-time. I hope we use this pattern!
That would imply that node-creation happens at runtime instead, for example "if there is not already a node in ~/.tahoe".
additionally, there should be a prominent place for picking which network to be a part of (friendnet, testgrid, allmydata public grid, etc). Is that a dropdown with the easy choices? A means to discover their friend's introducer.furl?
yes, totally.
later, create some kind of manager/preferences for multiple nodes, but initially, just create the one if it doesn't exist. if it does already exist, have a suppressible popup that would allow an overwrite/cleanstart.
Hi,
I can help a bit on this bug. I have already messed with py2app to generate .app packages and I have some code to automatically generate DMG images.
I first tried to add some basic options to py2app and ran it, to see if everything is ok. Unfortunately, it seems the latest version of modulegraph (necessary for py2app) is in conflict with the setuptools version that is used in the project (ImpLoader is part of pkg_resources).
I could try to patch modulegraph to get it working, but I don't want to mess too much my current environment. Can tahoe be built under virtualenv?
I've built tahoe using virtualenv 1.9 with pip 1.3, as I describe in #2055.
I don't know if tahoe's setuptools (zetuptools) is invoked by that process.
Here is another reports of a similar-sounding bug:
https://bitbucket.org/ronaldoussoren/modulegraph/issue/18/attributeerror-imploader-instance-has-no
@leif: py2app integrates with setuptools, and it needs modulegraph to recognize the module dependencies of the software.
@zooko: Yes, this is a recent bug. Is there a specific reason why the setuptools version is forced?
Replying to geal:
What do you mean, "forced"?
In setup.py, line 73:
And there is setuptools-0.6c16dev4.egg at the root.
Oh, I see, per comment:62699, you think the [particular version of setuptools bundled with Tahoe-LAFS]source:setuptools-0.6c16dev4.egg is part of the problem. Do you know what versions of pkg_resources have an ImpLoader that is compatible with the latest modulegraph? Per #2044, we are very interested in upgrading our bundled version of setuptools for other reasons (SSL verification of downloads).
Oh, and while you are thinking of that, please notice a related bug that is bothering a user right now: #2079.
I use setuptools 1.1.4 with py2app. Maybe that version is a bit too recent, but I'll test it anyway. The documentation for setuptools indicates that upgrade works correctly.
Attachment 0001-use-a-recent-version-of-setuptools.patch (429932 bytes) added
Setuptools upgrade
Hum sorry, I just thought after the fact that I could send a pull request for the setuptools upgrade. I'll send it right away.
So, packaging a .app works, but starting tahoe is "challenging".
It apparently requires a Tahoe.home file (I can directly put it in allmydata-tahoe.app/Contents/), then it needs the tahoe support script, and this one tries to load allmydata-tahoe==1.10.0.post42.dev0.
Could you explain the rationale behind this startup system? It may require some Mac specific tricks to make the packaging work.
Replying to geal:
Is it a problem that it is trying to load allmydata-tahoe==1.10.0.post42.dev0 ? That version number is supposed to be automatically generated, so that the version number that the tahoe script is trying to load always exactly matches the version number in the package. Are those numbers different in your setup? If so, we should investigate why.
The version number is not a problem. I was just wondering why there was a level of indirection while loading tahoe, instead of just importing the module directly.
Py2app finds the required code by parsing the Python code and finding all the imported modules, so when code is loaded in another way, it must be specified directly in the configuration (it's not always a problem, but some modules can be missed).
If I can get directly to the real entry point (is it src/allmydata/client.py?), I can make the packaging a bit more robust, because py2app will find everything.
Okay, the real entry point is… let's see… [in setup.py]source:trunk/setup.py?annotate=blame&rev=37c8b733a57dbbc4f9db0b3c8427f4e07994c3fa#L460:
So the real entry point is [allmydata.scripts.runner:run]source:trunk/src/allmydata/scripts/runner.py?annotate=blame&rev=3ee950f09ed8b7f6cc72a98c26eefe9e02c11d85#L150.
geal: there's an alternative entry point in source:static/tahoe.py which is intended for use by static packaging systems like bbfreeze and py2app. It has only been tested recently with bbfreeze.
In particular, source:static/tahoe.py explicitly imports all the modules which would otherwise only be imported dynamically by name.
I now have a working package :)
I encountered some packaging errors with nevow and formless (they load outside files with pkg_resources), and I removed the check for setuptools to let it launch (I'll see of there's a cleaner way).
Is there a test cluster I can connect to with the client I just launched, to check that everything is ok?
Replying to geal:
Yay!
Could you show the packaging errors?
Replying to geal:
Could you show the problem that prevented it from launching before you removed the check for setuptools?
Replying to geal:
wiki/TestGrid
Replying to [zooko]comment:31:
Py2app stores all the dependencies in site-packages.zip, and pkg_resources has difficulties getting resources from there, but py2app has the 'packages' recipe to move them out of that file, so no problem here.
Replying to [zooko]comment:32:
Here is the stacktrace:
And here is the check I removed:
}}}
user-friendly installer for Mac -- for my Mom!to build a .pkg installer for Mac OS X 10.9build a .pkg installer for Mac OS X 10.9to build a .pkg installer for Mac OS X 10.9 Mavericks (intel-x86-64)Note, I just created #2303 which is about acquiring and setting up a dedicated OSX buildslave.
We need a new automated packaging test for this work tracked in #2304. When #2303 is complete a buildslave will execute this test.
We are unsure whether the .pkg files will be compatible across Mac OS X point releases. For the packaging contract, we intend to just create one .pkg for OS X 10.9 (Mavericks), but also check whether it works on 10.8 in order to document this correctly.
An update on the mac package.
The 182-osx-packaging-5 branch has a make target called 'build-osx-pkg' that builds the pkg and runs a test. I tested the resulting package on OSX 10.9.5 (Mavericks) and in OSX 10.10.x (Yosemite). More testing of both package build and the resultant package with test reports welcome!
182-osx-packaging-* has been merged to master. The OS X package still needs wider publicity and testing before we can consider this fixed.
FYI, I recently learned that the OS-X "Automator" application can be used to build double-clickable apps which run a shell script. It's a pretty easy process. We could use this to build a "Tahoe" .app file (with icon) which makes sure a client node is running, and then pop open its web UI page. We could probably also build the .app first, then copy a pre-built copy of Tahoe (and dependencies, virtualenv-style) into the .app directory, then bundle the whole thing for distribution.
Some notes: launch Automator.app, choose "Application" from the document-type wizard, drag a
Library/Utilities/<Run Shell Script>
into the box, set "Pass input:" toas arguments
(which lets you drop documents on the new .app and learn their pathnames, might be useful for upload or something), modify the shell script to your heart's content, then Save.We already have a stub double-clickable script in the OS X package, so we don't need another tool to create it. Please open another ticket for the functionality of "making sure that a client node is running and popping open its web UI page". (When writing the specification of this ticket, please don't overspecify implementation!)
Incidentally, the OS-X .pkg files for each commit (such as they are), created by
make build-osx-pkg
, are currently being uploaded to https://tahoe-lafs.org/source/tahoe-lafs/tarballs/OS-X-packages/ (bymake upload-osx-pkg
).