Does Lektor assume too much?

When running Lektor, it tries to solve so many things that – I believe – shouldn’t be solved by it:

It tries to reinvent Python packaging using a non-standard installation instruction curl -sf https://www.getlektor.com/install.sh | sh. Why? virtualenv, conda and pip solve this problem way better than Lektor ever can.

When running lektor server, it runs pip install. Why? I have a requirements.txt file and ran pip install myself three seconds ago.

Then it tries to install extra packages in packages/ (and often fails to update them because of cached files). Again, why? Shouldn’t I install them using pip install -e? And why do they have to be in packages/ anyways? I believe the location of a package should not matter for pip, and if I used pip install -e they could be anywhere.

Then lektor-webpack-support tries to run yarn install or npm install (and does so badly), and then webpack --watch. This is not an issue with Lektor, but an example of how this “let’s solve all the things” approach trickles down into plugins as well. Yes, you may run webpack --watch, but I should run yarn install.

I propose to get rid of most of these things, and replace them with standard Python packaging tools. That way Lektor will have to solve less problems, have a smaller code surface and less possibilities for issues and and will be easier to maintain. Also, when exclusively using standard installation tools, Lektor installations will be easier to maintain and understand for people who understand pip (everybody I assume?).

[nixjdm]

In general, Lektor should be easy to run and setup, even for non-technical people.

Shouldn’t I install them using pip install -e

Packages (plugins) need to be known to Lektor. If they are in packages/ that is one way for them to be discovered. They can also be installed with lektor plugin add. Internally, the first does install the package with pip install --editable, and in the later, it simply uses pip install to grab it from pypi. On the file system, the later is in a cached dir, and not packages/. Lektor is aware of both locations so it can invoke the plugins when run.

Lektor could be enhanced to use a package that is installed by a manual pip install. Lektor would still have to be told where/how to find it though. Presumably with an addition to the projectfile, similar to a settings.py in Django. The location doesn’t really matter, so long as Lektor knows what the location is (or it’s name if installed in the env - something to discover it by).

Lektor installations will be easier to maintain and understand for people who understand pip

That’s true, the project would be smaller and easier to maintain. However, this is not the exclusive target audience. I believe the original hope (which I share) was to make Lektor accessible to a wider group of people, and not just people comfortable with Python (and pip). It’s part of what sets Lektor apart from other projects like Django or Pelican. It should be possible to build a Lektor site without knowledge of Python.

All that said, I recently accepted a pull request to make plugin development easier to some Python devs. Similarly, if there are ways to make things easier for people who do know Python (or front end devs), then I want to.

[davidism]

I’d say close this.