Allowing data and the lite binary to reside in different directories

[Cogitri]

Hello,

right now lite assumes that the lite binary will be right next to the data directory - but that might not hold true in practice. E.g. linux distros would generally prefer having lite in /usr/bin while having the data in /usr/share/lite. It'd be nice if lite had a toggle to set that during build time - that could go hand-in-hand with #48 , e.g. by adding a "@datadir@" directive that's then replaced during compiletime instead of using the EXEDIR. I currently just patch around this for Alpine Linux.

[1bardesign]

Pretty straightforward to add the required build time machinery for this with a definition in cflags of build.sh 👍 Seems like it'd need a separate concept for DATADIR and EXEDIR lua-side and to move the existing code away from using the latter.

[Cogitri]

Right, that'd probably work too - I don't use C too often so I usually don't think of using definitions and macros :)

[rxi]

I don't want to encourage a decoupling of the binary and data folder -- that is, both should be kept in sync with one another and always remain a pair. I appreciate this makes lite difficult to package in regards to package managers, to keep in-line with the project's goals I want to encourage the practise of having a per-user copy of lite instead of a system-wide install.

[alerque]

I just bumped into this trying to setup packaging for Arch Linux as well. We can patch like Alpine did, but please reconsider this. If you want to allow for the use case of user-local software that's fine, but that's not how most Linux distributions work nor haw many of us want our software. Please try to limit Linux distribution to work the way macOS or Windows ecosystems work.

[MaD70]

@rxi: it seems that if one want both the coupling of Lua files to the executable and to adhere to Unix custom the bundling suggested by @sherief in #82 should be worth of consideration. For how to technically realize it see my comment (also in subsequent comments how to link statically SDL2).

In this way there will be a master copy of lite installed system-wide and possible customization (of Lua files) installed locally per each user (only customized Lua files need to be copied from memory to the local file system; so if a user does not customize lite, it should not copy anything locally). I suggest to have a re-bundling option also, where the lite executable is re-bundled with customized Lua files and is written locally.

A problem that I see, even with the current un-bundled distribution, is with syncing updates with customization, but I have no suggestions to offer at this time.

[MaD70]

@rxi another option is Zero Install, which is concisely described as:

… a decentralised cross-platform software installation system available under the LGPL. It allows software developers to publish programs directly from their own web-sites, while supporting features familiar from centralised distribution repositories such as shared libraries, automatic updates and digital signatures. It is intended to complement, rather than replace, the operating system's package management. 0install packages never interfere with those provided by the distribution.

A short introduction of 0install features is found in its documentation, a longer overview is this OSNews article: Decentralised Installation Systems.

But this requires that users download 0install before installing lite and I'm not sure this is in line with your minimalist philosophy.

[1bardesign]

I feel like all of this is kind of solving a problem that doesn't exist - many people on many different systems are able to run lite as it is.

It isn't hard to have system wide sdl2 insyalled. It isn't necessary to "install" anywhere beyond whacking it onto your path, which can be done with a symlink or editing your path directly. It isn't hard to build from source, and the source is pretty friendly to modification in the case where package maintainers want to be ideologically correct about where some lua scripts go.

3k stars implies this is much more widely used than any of the authors other projects, and maybe concessions to the public will end up being made but it's still a little minimal editor made mostly by a single author, originally for their own use. Approaching it as if it's the same thing as vscode with the same mass consumption standard practice goals seems a bit backward.

I should be clear that I think a define for where the data scripts go would be good to see and easy to implement, and would keep package maintainers happy. I've got a feeling all this exe bundling stuff is more or less irrelevant though.

[alerque]

@1bardesign That is too dismissive a treatment of the actually root of this issue report. OS packages are how many people get their software. There is a simple to fix BLOCKING issue that distros are having to monkey patch around.

1. Distro packages cannot just "whacking it into your path". Systems have a limited set of paths that work out of the box for everybody, we *have to put executable in those paths. Following the defacto file system layout used by tho vast majority of distros, the right place for something like this is /usr/bin/lite.

2. Disto packages cannot just dump a whole bunch of support files in a directory called "data" inside /usr/bin!

That's a very real problem and there is no easy mechanism provided to separate the two. It is patchable, but being able to put something in /usr/bin shouldn't require patching. Also patching is brittle, already I had to tweak the Alpine patch to work on the latest version of the code because context lines changed. That's not how software distribution should work.

[1bardesign]

/opt/lite seems like it'd be a much more sensible place than /usr/bin in its current state. Monolithic "everything together" software distribution is a common phenomenon. Not everything in the world complies with the ideals of FHS, and acting like maintainers are unaware of this is pretty strange.

As I finished with before:

I should be clear that I think a define for where the data scripts go would be good to see and easy to implement, and would keep package maintainers happy. I've got a feeling all this exe bundling stuff is more or less irrelevant though.

[CtrlC-Root]

I'd be happy with a mechanism to keep user specific settings in a user-specific path. Ideally under ~/.config/lite/ where ~/.config is detected from XDG_CONFIG_HOME [1]. Alternatively as a simpler implementation maybe just looking for $HOME/.lite.lua and loading it if it exists on startup.

I don't want to encourage a decoupling of the binary and data folder -- that is, both should be kept in sync with one another and always remain a pair. I appreciate this makes lite difficult to package in regards to package managers, to keep in-line with the project's goals I want to encourage the practise of having a per-user copy of lite instead of a system-wide install.

I can certainly see the appeal of keeping the binary and data files together. In trying to learn more about what the project's goals are I see in the README.md file that:

it aims to provide something practical, pretty, small and fast, implemented as simply as possible; easy to modify and extend, or to use without doing either.

I think there is a tradeoff between implemented as simply as possible and to use without doing either. You can't possibly anticipate or cater to all of the ways users will want to use your software nor do I think you should try. Following common existing conventions (i.e. XDG) is a great way to meet users half-way though. If the mechanism is there the end users will often already know what they need to do to leverage it for their own use case.

By the way, I'm the only human user on my system and I still prefer to use a package manager to manage my software. I use a lot of different packages and it would be a real pain if I had to maintain all of that software in my home folder manually. This is especially useful since I often use different local users on my machine to keep my work and personal files separate. I'd rather not have to keep two separate copies of the editor, the data files, and my user settings.

/opt/lite seems like it'd be a much more sensible place than /usr/bin in its current state. Monolithic "everything together" software distribution is a common phenomenon. Not everything in the world complies with the ideals of FHS, and acting like maintainers are unaware of this is pretty strange.

If I'm installing something in /opt it's because I can't be bothered to package it. I'd still prefer those files to be owned by root:root with a file mode of 0644 though.

1. https://www.freedesktop.org/wiki/Software/xdg-user-dirs/

[CtrlC-Root]

I just found #112 which is actually what I'm after. I've gone ahead and patched my copy to do what is suggested in that thread and load a configuration file from the user's home folder. This might be something we could accomplish with a plugin and therefore not require any changes to the editor itself.

[fpesari]

I don't want to encourage a decoupling of the binary and data folder -- that is, both should be kept in sync with one another and always remain a pair. I appreciate this makes lite difficult to package in regards to package managers, to keep in-line with the project's goals I want to encourage the practise of having a per-user copy of lite instead of a system-wide install.

I am a packager and today I tried to create an openSUSE package for lite. I had to give up precisely because of its lack of adherence to the FHS and this is sad because it is a really great editor with no real alternatives in terms of both lightness, beauty and simplicity and I'd love to spread it to the openSUSE community 😃