So my answers to the above questions in short: 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. I had lots of files added there when testing the last PR and removed them again. It's also a good idea to not touch ~/.cheat. I also like ~/.cheat for easy access when editing files. 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. (bonus question: Where to put pre-packaged cheats in that case? See below for an option.) One use case would be to make cheat available for all users on the system when there is no distribution package available. If someone insists on installing cheat with sudo they can still do that, but it will be the minority.
It should just behave like a normal Python package. cheat itself can not and should not make this decision. 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 ENGINE MAC OS X SIERRA INSTALL#
Then you install any package into that custom Python without messing up the system Python.Ĭheat fits nicely with the latter two install options and should work with both without needing sudo. Another option is to install a custom Python distribution belonging to the current user. 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. 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. 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. Hopefully, now that we're resolving these installation-related problems soon, I won't have to bother either of you much longer after that 😄
Otherwise, I'll think about this for a bit, and will make a judgement FYI, I'll ask you two to re-test your builds before I merge #432, once again to ensure that I don't break your packages. Also, upstream maintainers will likely require the use of sudo when installing from third-party repositories regardless.
I don't think cheat is a particularly high-risk application, though, from a security perspective. We'd be fully XDG-compliant that way, though we'd be arguably be violating Python's best-practices. If we decide that we don't mind mandating the use of sudo during the installation process, we could store system-wide cheatsheets to site_data_dir, and personal cheatsheets to user_data_dir. There is another possible approach, of course: It makes it easy to keep them backed-up and tracked along with the rest of my dotfiles.) (FWIW, I personally keep my own cheatsheets in ~ intentionally. By storing user-defined cheatsheets in ~/.cheat, we solve that problem, even though we do pollute the user's home directory somewhat. If I installed user-defined cheetsheets to the same directory, it is probable that users would have their own cheatsheets overwritten every time cheat was updated, which we obviously want to avoid. That being the case, I decided to install "system-wide" cheatsheets to the user_data_dir reported by appdirs. I did this because, per #351, we're trying to obviate the need to use sudo when installing cheat. Ultimately, I decided to keep user-created cheatsheets in ~/.cheat by default, contrary to the XDG guidelines. I think cheat should now install successfully. When you have a moment, please re-test your installation from this branch.
0 kommentar(er)
