Try out Pipenv

[yagebu]

This is an attempt to see if pipenv can be a safer alternative to using Lektor's builtin plugin mechanism to build the site.

Edit: I've personally been using pipenv for a while now for my personal Lektor projects and it's been a joy to use (just like poetry would be as well I guess). I know my dependencies are locked and will work unless I explicitly try to upgrade. I think the same would work well for this repo - these updates could be automated with dependabot or renovate.

[anmsh]

Please consider Poetry as well.

Some references to help in your research:

1. https://www.reddit.com/r/Python/comments/jmbkiu/whats_the_latest_on_pipenv_poetry_etc/
2. https://www.reddit.com/r/Python/comments/odwja8/python_best_practices_for_a_new_project_in_2021/
3. https://www.reddit.com/r/Python/comments/l7qase/virutualenvs_which_one_in_2021_venv_virtualenv_or/

[yagebu]

Please consider Poetry as well.

I did consider poetry. I don't think there's much difference between the tools for this use case and I've just had more experience with pipenv, which has worked very well for my lektor projects.

[dairiki]

@yagebu I do think this is the way of the future. Much cleaner, more stable. Great work.

We should almost definitely work on moving Lektor out of the package management business and in this direction. Because of backward compatibility concerns, we'll probably first have to deprecate Lektor's plugin management facilities, and update Lektor's documentation to describe and recommend doing things without using Lektors plugin management: i.e. using pipenv (or poetry, or plain old pip) to manage a virtualenv for each Lektor project.

Before we've done that, my gut feeling is that we should be eating our own dog food here. It's good to have lektor-website as an example of the recommended/canonical way to put together a Lektor project. As long as the Lektor docs still recommend the use of lektor plugins add, dropping local plugins into packages/, etc. it is confusing (and looks a little bad) to use a completely different method of managing plugins here.

[dairiki]

FWIW, I am now managing all of the Lektor sites (and most of my Python projects, in general) with PDM. It's working very well for me.
(For a while, I tried using poetry with some of my projects and PDM with others. PDM worked better for me, so I've now converted them all to PDM.)

PDM has matured to the point where I think it works very well. PDM is a generation more developed that pipenv, so supports things like scripts, dev requirements, etc. pretty well.

E.g. from a clean clone of a project repo, when properly configured, all that is necessary is:

# create venv, install requirements (from pdm.lock)
pdm install

# run the `server` script, defined in pyproject.toml, e.g. `lektor server`
pdm server

There is a github action that makes use of PDM in Github workflows straightforward.

For me, PDM has advantages over poetry in that it's more recent, so more standards-based (e.g. PEP 621 support). It is under active maintenance and development. And it makes more sense to me — for whatever reason, I can figure out the appropriate PDM command to accomplish a task easier than with poetry.

If, for comparison, you'd like me to come up with an equivalent PR to this one, except using PDM, let me know.
For comparison, #377 is a roughly equivalent PR that uses PDM rather than Pipenv.

[yagebu]

Closing this one, I'm not motivated to follow up on this one. I'm not using pipenv myself anymore to manage my Lektor environments, rather I'm just using plain old virtualenvs (using uv for speed). Not against using PDM instead.