Can not create a new project because of VFS limitations

[jurgenvinju]

Describe the bug

rascal>import util::Reflective;
ok
rascal>newRascalProject(|project://my-new-project|)
|std:///IO.rsc|(9979,210,<355,0>,<366,24>): IO("-1: Cannot mkDirectory on a rascal uri: project://my-new-project")
        at *** somewhere ***(|std:///IO.rsc|(9979,210,<355,0>,<366,24>))
        at mkDirectory(|std:///util/Reflective.rsc|(12402,6,<319,24>,<319,30>))
        at $shell$(|prompt:///|(0,32,<1,0>,<1,32>)ok

[jurgenvinju]

This is rather counter-intuitive, or at least not symmetric, as using an existing project is exactly done like so exists(|project:///existing-project|)

[DavyLandman]

Quoting from slack:

Looks to me more of a problem with the project scheme. You cannot call mkdir to create a new project folder. And VsCode projects can be anywhere in disk, it's a virtual scheme, it depends on the current workspace which file a certain project uri is pointing at.

To add: I don't understand how mkDirectory(|project://my-new-directory|) is suppose to work, no matter what the context.

[jurgenvinju]

me too. typically the ISourceLocationOutput implementation for the specific scheme would implement something different for each implementation. For example, project in Eclipse would run IProject.create...

[DavyLandman]

But where would that project end up? A project is defined by it's directory. So how could we figure out where that project should live? Except that we would have to ask the user via some UI? Like example, I say mkDirectory(|project://my-new-project|), where should the my-new-project directory be created on disk? Based on what logic?

[jurgenvinju]

It depends. VScode has defaults for new folders, but the workspace concept could also be searched for a probable sibling project (i.e. most recently edited) or the prefix that occurs most among the workspace folders, finally we could ask with a popup indeed; i don't know yet what makes most sense. For myself I'd like the new project next to my other open projects. How about you? At least people can always move a new project to a better location.

For eclipse it would (already does?) nest in the workspace folder.

[DavyLandman]

My workspace sometimes contains projects not close to each other on disk.

I think we might need to develop the #248 properly, and after asking where it should be saved, create that folder and then start the rascal code that builds the project.

VScode has defaults for new folders

Can you point me towards some documentation of that? The VFS seems to work with absolute paths? The Workspace has a rootPath property, but that's just the folder of the first entry in the workspace?

[jurgenvinju]

Yes, the rootPath is the default when you open New File.... Try it in VScode. I read the code yesterday.

[DavyLandman]

That's for inside of a project. making a new project would then end up as a sibling?

Also, what if there is no project open yet (for new users)?

[jurgenvinju]

It all boils down to understanding better what the project:// scheme is supposed to do in the VScode context. We can't hide this in fancy UI, because the scheme is not limited to UI interactions. Or we come up with a different scheme that fits better with the way VScode works. After all, project:/// was really an Eclipse-inspired concept originally.

[jurgenvinju]

It also relates to what |scheme://|.ls is supposed to do in general. This does not work correctly in the Rascal context either. I.e. for project in Eclipse it could list all the projects, but what about the other schemes? We should include this in the discussion because there might be a solution that covers many other opaque/logical URI schemes that we have.

[DavyLandman]

I think at one point I actually implemented that in eclipse it would list the projects. Is that not working anymore?

[jurgenvinju]

I don't know by heart what rascal-eclipse does anymore. Yes, that would be great for all the other implementations of project as well. currently not the case. But also we'd have to think about what mkDirectory means for all these (logical/opaque) schemes..