Re: How to use project.el

[Dmitry Gutov <dgutov@yandex.ru>]

On 21.11.2020 03:03, excalamus@tutanota.com wrote:
> 
> 
>> To get the most benefit from the package, you should install the latest version from GNU ELPA ('M-x list-packages', then install 'project'). The latest version is 0.5.2.
>>
>> To see the full list of commands defined in that package, type 'C-x p C-h'.
>>
>> You can also read the full description of the package with 'C-h P project RET'.
>>
> Thank you, I was unfamiliar with 'C-h P'.
> 
> I have updated to 0.5.2 and it's more like what I would have expected.  Actually, several functions mirror my own project management code.  My use-case is, of course, specific to me, but I see overlap.  I wonder if any of my code, or its ideas, may be useful?  Who is project.el's point person?

That would be me.

>   I develop Python and prefer to interact through shell directly by sending commands to the comint buffer.   At this point the main command is 'xc/sh-send-command'.  This sends something like 'python main.py' or 'pyinstaller main.spec' to the appropriate shell and steps.  I create a shell, either by name or on the fly, similar to 'project-shell' with 'xc/create-shell'.  Everything else is just a helper.
> 
> It's all hacky stuff I've made in the moment over time.  This weekend, I hoped to create project profiles, a plist or something, with :root, :venv, :entry-point-file, etc., so that I can switch between shells and associated command sets easily, maybe also formalize it (hence my looking into project.el first).
> 
> Thoughts?

In general, I like things to happen automatically for the user. For 
instance, if you are working on a Python project, shouldn't there be 
some file in the project root directory which will indicate which 
virtualenv to use?

Then your workflow could be something like call (project-root 
(project-current)), then read that file, then set the venv for the 
current buffer to the appropriate value.

And :root, is that project root? The idea in project.el is that you can 
write a function which will determine it, again, programmatically, 
based, say, on the current directory (usually by traversal up the tree 
and looking for some directory markers).

Of course, you can whip up a project backend which will plug into 
project-find-functions, but allow you, as the user, to set up everything 
manually, with manual switching between "profiles", etc. I'm just not 
sure why you would prefer that.

As for switching, there is the project-switch-project command.