Re: [Gnumed-devel] Mac packages

[Wolfgang Keller]

> While a tarball *can* be put inside a downloadable Mac .dmg, this
> would achieve little more than to supply, from the wiki, a link
> called "Tarball for Mac".

The only legitimate way to distribute applications for the Mac has
always been as "zero-install" application bundles ready to
"double-click-and-use".

The only thing that would be "allowed" to require an "installer" on the
Mac is the PostgreSQL server.

But even for PostgreSQL there are now app bundles available, although
they may not always be maintained up to date:

http://postgresapp.com/
http://www.postgresqlformac.com/

Obviously these run with the current user's login, so this is not
really suitable for a multi-user environment.

> The problem on the Mac is that Apple's operating system has never
> supplied, on a base system, the various dependencies needed by GNUmed
> and AFAICT has not provided an organized way to manage a
> side-installation.

You don't "install dependencies" on the Mac. Never. On the Mac, all
applications are entirely self-contained, installer-free bundles.

Yes, there are wxpython applications that come as a MacOS app bundle.
Don't ask me for examples, I don't have access to a Mac any more. A
look at http://wiki.wxpython.org/wxPythonPit%20Apps should help to
fidn examples. A look at
http://wiki.wxpython.org/Optimizing%20for%20Mac%20OS%20X should help
for adaptation of the client implementation to the Mac.

The Phatch application (http://en.wikipedia.org/wiki/Phatch) has been
thorougly adapted for the Mac, among others. The developers even held a
presentation at a Pycon about wxPython cross-platform issues, the
video should still be available.

> A side-installation is required because some of the dependencies
> (like the needed versions of python) could otherwise conflict with
> what Apple has installed as its 'base" python which Apple has bent to
> its own use.

No. You *never* use the system Python for anything on the Mac. You
especially *never* install additional packages there or replace
packages within the system Python directory.

Python *developers* always use the "framework build" of Python. 

*End users* of Python applications on the Mac have nothing to do with
Python anyway, they just double-click the self-contained application
bundle.

> The choices available to GNUmed for Mac include:
> 
> - to piggy-back on an existing, side-install port system for Mac
> (e.g. MacPorts or Home brew)

Absolutely *never* use Macports for anything. It's a hopeless, pathetic
mess. It *will* screw up your Python installation thoroughly, among
others.

> - to develop our own side-install scripts, or

DON'T.

> - to supply a Mac GNUmed "app" (fat binary) which contains all the
> dependencies

The latter is the only legitimate way to distribute applications on the
Mac.
 
And it should be the only reasonable way on any other system as well,
btw. The requirement to "manage" dependency mess is an obscenely
degrading insult to end users who need to get actual work done with
their computers. And don't tell anyone who need to get work done with
their computer about #§$%&@! "administrators". 

> The limiting factor so far has been lack of a wx that can work with
> the existing MacPorts.

Again: *Never* use Macports for anything.

Sincerely,

Wolfgang