search

lektor / lektor-website

The main lektor website.
https://www.getlektor.com/
Other
160 stars 134 forks source link

BUG: Project.discover() not set when Lektor loaded with --project ARG #291

Open mountainash opened 4 years ago

mountainash commented 4 years ago

It seems that if the path to the Lektor project file is set but using the --project argument, Project.discover() (used for packages) is been set to "None", yet using the ENV LEKTOR_PROJECT alternative, as described in https://www.getlektor.com/docs/cli/ seems to work (I would have thought that they should both function, at the discover method, in the same way).

File: https://github.com/lektor/lektor-website/blob/master/content/docs/api/project/discover/contents.lr

xlotlu commented 4 years ago

Is this a documentation bug, or a real bug?

runfalk commented 4 years ago

Hm, I'm not actually sure. I definitely would expect the environment variable and the arg to have the same behavior (and probably give precedence to the arg so you can override it even when env is set).

For the discover method I'm not as sure. In order to be useful I guess we should change the docs and implementation of Project.discover() to respect both env and arg? Is there ever a scenario when you as a plugin author should side step the arg/env?

nixjdm commented 4 years ago

I think the OP may be a little unclearly worded, but I think I get the confusion.

--project / LEKTOR_PROJECT allows you to specify the project directory or projectfile, with a couple basic checks. I also tested both and verified they both behave the same way, as it looks like they should from the code. The arg does have precedence, by the way, and should for all env vars / args since that behavior comes straight from click.

.discover() allows you to run lektor from a cwd at or beneath the directory that contains a projectfile, similar to how git would recognize you are in a git repository. The method is a fallback and isn't called if other methods that determine the project's path are used.

If the project is specified, it is assumed that it is where a project actually lives, so if it doesn't find one that seems valid, it bails and does not walk back the directory tree. I think it was intentional that this does not walk backwards, because if you bother to specify a path, why would you specify a sub path and not the correct one?

I think https://www.getlektor.com/docs/cli/ should be amended to mention .discover() and clarify its use vs. --project. In my opinion no code needs to change here.

nixjdm commented 4 years ago

Is there ever a scenario when you as a plugin author should side step the arg/env?

I struggle to think of when it would be a good idea to modify the project path from a plugin, but I don't see anything preventing it. A plugin should be able to call from_path or discover wherever they like, and set the project path after it's already set, to anything.