feat: manual project adding

[Dimfred]

Hi,
I am missing the feature to add projects manually, so here is my version of it, let me know if you like this or not :)

In a nutshell:

• additional file which allows to add a project directly (Projects api extended is more like workspace now)
• for my usecase I also need the path of the project which is about to be loaded in the hooks, so I added that one too
• also I introduced a new flag, which skips the save / restore session check of whether the project to be saved / restored is a project of a workspace, I like to still have a session for the projects I was in whether I added it as a project or not

If you are cool with it I would add documentation

Nevertheless, loved your code, very clean and easy to read. Great work!
Cheers

[GnikDroy]

I took a quick glance and everything looks good and well written. Thank you for writing validators as well. So, no concerns on the code.

I believe this has been brought up before. #14 deals with the inverse of this for example.

Alternate ways that need to be considered

1. A .projections_project file in the project. The filename can be changed according to your preferences. The general gist is to add this file to your project and add the parent folder to workspaces list. You can even keep .projections_project in the global .gitignore so that git never tracks this file. (Similar options are available in other VCS). And if a VCS is not used, a empty .projections_project shouldn't hurt too much. It gets deleted when you delete the project.

─── W
    ├── A
    │   └── .projections_project
    ├── B
    │ 
    └── D

{ "~/dir", { ".projections_project" } }  -- An empty pattern list indicates that all subdirectories are considered projects (README mentions this)

2. Create an empty directory to host orphan projects. Create a symbolic link to all orphan projects in this directory. Then add this directory to workspace list.

─── orphan_projects
    ├── symlinked_dir_A
    │ 
    ├── symlinked_dir_B
    │ 
    └── symlinked_dir_C

{ "~/orphan_projects", {} }  -- An empty pattern list indicates that all subdirectories are considered projects (README mentions this)

Symbolic links can be created in Linux and Windows. Although, on Windows, you require administrator privileges.

If you go with the second option, you get an easy way to track orphan projects even OUTSIDE of projections (from terminal?).

I personally think this should be handled outside of projections. A well organized file system is useful everywhere. What are your thoughts on my ideas?

I am not opposed to the idea of adding this. The code looks good. Just doesn't seem like it is necessary.

[Dimfred]

Hmm, I think this wouldn't work for me. While coding I often use the source code of my dependencies as documentation, e.g. I jump into a poetry venv and then sometimes also change code there to adapt the dependency if it's not working for me. A venv can have a gazillion projects in it since it has a lot of dependencies, but I need only one maybe and also for a very short time, after that I normally delete it from my projects list.

If I understood correctly I would have to add all projects I DON't want to use to a orphan folder, while I only want to use one of them, so I would probably not be happy with the solution.

In project-nvim, which is similar, but without the session management you have both options, adding manually and automatically based on pattern, tho it doesn't scan a workspace dir. So imho manual adding is a valid solution, and it doesn't break the current behavior at all so I think it wouldn't harm.

Rightnow for example I don't use the automatic discovery at all. I just don't like it, and I don't see any value in reorganizing my workspace folder, everything is there even if something is orphaned I sometimes need it, so I like to have everything on one level to quickly find it. And with fzf n stuff I can pretty well filter everything so even if there are a million orphaned projs I'll still find everything in no time.

[GnikDroy]

If I understood correctly, I would have to add all projects I DON't want to use to a orphan folder, while I only want to use one of them, so I would probably not be happy with the solution.

You add projects that you want to the orphan folder. Other than that, I will look at your workflow and see if I can come up with something.

[GnikDroy]

I think the orphan folder + symlink method is functionally the same as specifying projects explicitly.
They just change where the bookkeeping is done (projections_project.json vs your file system).

You can even create a custom neovim :AddProject and :RemoveProject commands with the symlink method for ease of use.

[Dimfred]

Ah okay then I misunderstood, okay gotcha so what I would do is just add project as a symlink so it's available there, hmm got it, well essentially that would work.

Still prefer having the ability to just manually add projects. It's more finegrained and requires less anti-rules / filesystem maintenance on which should be in a workspace and what not.

Also one part here is having session also for projects, which aren't specifically in a workspace, that is something I am missing too. E.g. for projects which are enough for me to not be added to my recent ones, but I still want to keep a session for those.

[GnikDroy]

Can you clarify what you mean by "having session also for projects, which aren't specifically in a workspace".

Currently, shoudn't all projects be in a workspace?

[Dimfred]

So the current bahavior is like this in Session.store and Session.restore, you first call Session.info, Session.info only returns something if the path you are in is in the workspace, but as said sometimes you switch to a folder only to quickly change a file, I would like here a session to be stored, whether this folder is considered a project or not, basically this is what skip_session_check does.

Imo not all projects should be in a workspace, I for example have some "projects" which are in a google drive and pretty much scattered, I would have to add a lot of them as a workspace, and create super super custom rules for them to be available.

[GnikDroy]

Okay I understand. Hmm.

If I understand correctly, your solution, as well as the symlink trick, solves all problems encountered here. They just do the bookkeeping differently. Am I correct?

As in, does having a projections_project.json give advantages the symlink trick doesn't?

Note that the orphan_projects/ directory is a workspace itself, so sessions work normally.

[Dimfred]

So there is an edge case with this, imagine I have two main projects, both projects have the same dependency, if I add a symlink one of those will be overwritten cause it will have the same name, sure I could add the symlink with a different name indicating it belongs to that project, but that seems like extra steps
Hmm idk.

[GnikDroy]

There are some things I had in mind when developing projections:

1. The user should tell projections how to find a project, not what the projects are.
   The reason is simple. Telling it how to find a project lends well to automatic project
   discovery/maintainance.

   If I add the ability to manually add projects. The user always has to worry about
   if the project list is in sync with what is in the filesystem.
   While this is true for workspaces as well, they tend to change less frequently.

   In my opinion, having to manually list projects in projections is a failure as a project management plugin.
   The plugin should be able to do this. Perhaps the current implementation could be made better.

2. Don't recursively search for projects. This is inefficient and unnecessary.
   People often like to put similar things in similar places. I want the plugin to feel instant.

So keeping that in mind, perhaps I could find alternative ways to make the plugin better.
I really don't want you to specify projects manually,
because I think projections should take care of that headache.

Projections could maybe figure out the usage pattern automatically and "suggest" projects?

How does this sound? I will have to figure out how to do this though.