Default folder locations for Mac OS X

[macfreek]

I noticed that on Mac OS X (or any posix system), the default locations are in setup.py:

source_dir = u'/var/lib/tvgrabpyAPI'
opt_dict['etc_dir'] = u'/etc/tvgrabpyAPI'

while the default location in tv_grab_config.py are:

opt_dict['etc_dir'] = u'/etc/tvgrabpyAPI'
opt_dict['xmltv_dir'] = opt_dict['home_dir'] + u'/.xmltv/sources'

Three (related) comments:

1. The source dir is not the same in setup.py and tv_grab_config.py.

2. The correct default on Mac OS X should be respectively opt_dict['home_dir'] + u'/Library/Preferences/com.github.tvgrabbers/sources' and opt_dict['home_dir'] + u'/Library/Caches/com.github.tvgrabbers/sources', or possibly all in opt_dict['home_dir'] + u'/Library/Application Support/xmltv/'

3. source_dir in setup.py should possibly be dependant on the package manager. For example, the install location for tvgrabpyAPI for me is
   /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/tvgrabpyAPI/. The most logical install location is /opt/local/var/lib/tvgrabpyAPI.

[hikavdh]

Two things, maybe more.
First I did not at any time look at macOS and I do not intend to do that. First it is linux and I will treat it as such, second me and mac hate each other, even more then I dislike MS and that goes back way farther then when mac embraced linux. It structurally always has tried to think for me and most of the time has thought wrong!
Secondly the source_dir in setup.py is only to place a backup copy of the two main json files and as such is the same as the backup location in the main program, which is the same location used as when you run --install as root.

[hikavdh]

There is something to say for choosing /var/local or /opt/var (/opt should be a simlink to /usr/local and /opt/local does not exist in any linux or unix scheme!) but I have so far only seen /usr used this way. I use gentoo which is hardcore linux.

[hikavdh]

Let me elaborate a little. Apple adopted linux as their kernel, like Novell did and as MS will do in due time. Linux (and Unix) or Posix have a directory scheme. Adopting the kernel is adopting the scheme. The differences should only be in their X implementation. /opt/local does not exist in any variation as it is a double. At present there is a movement (I applaud) to get rid of all extra and superfluous directories in this scheme. /bin and /sbin should move to /usr merging with those in there, /opt and /usr/local are the same. I have them simlinked.
This program is outside X, so mac-OS should be 100%% linux in this respect and there should be no difference!

[macfreek]

Hi Hika,

I see you have a strong opinion on this. I'm not going to defend the way Apple selected paths. I don't like some of their choices either. That said, this is the system I have to deal with. Now I fully understand and appreciate your decision not to write a letter code for this hateful OS :). However, would you be willing to consider code contributions?

That said, I have a few comments to make about your rant:

• You mentioned that mac-OS should be 100% linux. No, it is not. It is Posix compatible (and even Posix certified), but it does not follow FHS (for good or -arguably- bad). Also, Mac OS is not based on Linux at all. It is based on BSD (the Mach kernel to be specific).
• Posix does not enforce a directory structure, the Filesystem Hierarchy Standard (FHS) does. Unlike Mac OS, most Unix version thankfully follow the FHS. Unfortunately, that's no guarantee it is all the same. Let's consider FreeBSD which both has a /usr/local/etc directory and a /etc, based on how you installed a piece of software (manually or with a package). You and I may not like this (well, I don't), but that's just what the distribution uses. Hard-coding /etc breaks with that.
• As for /opt/local, this is a choice by Ports, a Package manager. This is not a standard Mac OS path. I previously used Fink, which used /sw. Ugly? Yes! In my power to change? No.

I propose to keep this closed and focus on user-specified ways to change default paths. I can perfectly live with software that decide to ignore all those cockamamie defaults paths dictated by Mac OS X. I have a harder time living with software that hard-code paths without the option to customize it. It's no coincidence that I opened #4 first. Flexibility is key.