cheat: Can't install on macOS

Running into a similar issue as #420 on macOS. Installing without CHEAT_PATH fails:

error: could not create '/usr/share/cheat': Operation not permitted (this dir is protected since High Sierra and can’t be modified)

With CHEAT_PATH set, it fails a bit later:

error: could not create '/etc/cheat': Permission denied (can be modified with SUDO-permissons)

When looking at setup.py, both folders are mentioned there, but only the first can be overridden. I don’t know of any other Python package that writes to those paths. How about sticking to user-folders and letting the platform itself (like Homebrew or a Linux package maintainer) choose if and where to store those “shared” cheat files?

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 16 (9 by maintainers)

Commits related to this issue

Most upvoted comments

I’m in favor of a approach that doesn’t require sudo, although I don’t have much experience with Linux so I can’t say for sure whether that is the approach you should take.

To weigh in on this: It’s bad practice to install packages into the system Python using sudo because it can interfere with system-provided Python packages. This is true for both – Linux and macOS. General practice is to either use pip install --user XXX, which will still use the system Python, but install the package to the current user’s home folder only. Another option is to install a custom Python distribution belonging to the current user. Anaconda and Pyenv are both doing that. Then you install any package into that custom Python without messing up the system Python.

cheat fits nicely with the latter two install options and should work with both without needing sudo. If a (Linux) distribution decides to package cheat, they will integrate it into the system Python themselves and maybe put files into /etc/cheat if they seem fit. cheat itself can not and should not make this decision. It should just behave like a normal Python package.

If someone insists on installing cheat with sudo they can still do that, but it will be the minority. One use case would be to make cheat available for all users on the system when there is no distribution package available. (bonus question: Where to put pre-packaged cheats in that case? See below for an option.)

Keeping user cheat files in ~/.cheat and pre-packaged cheats in user_data_dir is totally fine and doesn’t break the setup of existing users. I also like ~/.cheat for easy access when editing files. It’s also a good idea to not touch ~/.cheat. I had lots of files added there when testing the last PR and removed them again.

One more thing to consider: Is it necessary to even copy pre-packaged cheat files to user_data_dir or could they just live in the package with ~/.cheat having higher priority for equal names? If I delete user_data_dir, should it get re-created after each update? If pre-packaged files would stay inside the package, it would also work nicely when installing it for multiple users with sudo pip.

So my answers to the above questions in short:

  • “keep user-created cheatsheets in ~/.cheat” - Yes, great.
  • “install “system-wide” cheatsheets to the user_data_dir” – OK, but they could also stay in the Python package, which would make them available system-wide without much hassle.
  • “we don’t mind mandating the use of sudo” – I would avoid sudo together with pip at all cost. Linux maintainers requiring sudo apt/yum/etc is different.