Manage the files as a project

[aoloe]

When I first saw the directory mu-editor / pygame zero files layout I really liked it: a sane default for a new project, ready to be used.

But pretty fast, I recognized that what I was seeing, is not supposed to be a project but the place where I should put all my files. Even if completely unrelated to each other.
Personally, I like to teach my kids to create a new directory for each game they are creating (and to think a bit about what a good location could be).
And, of course, I work that way myself!

This choice -- that have been made to simplify the mu-editor -- has multiple consequences (import, file.open, file > open/save) that are already covered by several other tickets.
This ticket is about the general idea, that Mu-Editor should better support the workflow where each game lives in its own directory.

Personally, I'm used to work with software that has not the concept of project, but does automatically behave in a sane way, when your files are in the same directory.
For that reason, I'm probably not the best person for suggesting how to implement it (except that I would love to have a solution that can do without a left pane with a tree view of the project files!).

Any idea how Mu-Editor could better support directory based projects?

[aoloe]

Travelling around... I have some time to think : - )

The "simplest" solution I can think of:

• Automatically detect the current "project"
• If a project is detected, use it as the root for the relevant actions.

I can only speak for the PyGame Zero mode, since it's the only one I have used until now.
Here a few ideas, for starting the discussion...

Detecting a project:

• get the current file's path
• if the directory contains one or more typical PyGame directories, use it as the root of the project
• otherwise, look in the parent directory for the "images" & co directories
• go up n directories (where n is defined in the settings file) and look for the root of the project.
• if no project structure is found, it's not an issue, just give up and keep the default behavior.

If a project structure is found:

• show the name of the directory (as the project name) in the status bar
• default to the project's root for file > open, file > save as, images+sounds+... buttons
• probably keep the setting in the background, when creating a new tab, to set its dfault path when first saving it.
• if the file is not at the root of the project or is not named after the directory (my-project/my-project.py) and is not main.py look for such a file at the root of the project and, if it's the case, add a "Project" button next to the "Play" one, with the same icons.

Some more details:

• The project is detected when opening the file
• When saving a new python file an empty directory, ask for creating the project structure

... just ideas, inspired by the nice country side passing by : - )

[aoloe]

had a workshop today.

too few kids showed up with a laptop and one of the mentors had to lend hers.

it's really disturbing that the mentors and kids files are mixed up.
all images together.

the "bad" project management is (with the missing image scale in pygame zero and the fact that there is no straight forward way to scale, crop and add transparency an image on windows) the only drawback in mu editor that the kids had a hard time with!

[aoloe]

from 1.0.2 mu-editor uses that latest directory for opening and saving files.

that's IMO much better than the previous behavior.

the change makes this ticket less important (for me) than it was before, but i prefer to leave it open.
pygame-zero programs have a very strict structure and i think it would be nice if pygame-zero could let the idea of "project" shine through.
(all common IDEs seem to work in this way, and it might be good for kids to learn about it.)

[devdanzin]

Maybe the simplest way to do this would be to mimic git and have the project marker be a specific dot file or dot directory? Then extend the new, open and save as actions to also handle projects: folders with such a marker inside.

[aoloe]

personally, i would prefer not to have one more dot project file (format).

lately, i've been using visual studio code, and their way of adding folders to workspaces seems interesting to me.

[devdanzin]

Took a look at how it does it, seems simple enough that we could experiment with something similar. If we're going to support projects, explicit projects are a must IMO. For automatic detection to work for very young and/or disorganized users, it would also require automatic creation.

IIUC, VSCode keeps a workspace.json file per workspace in a central config store. You can then add folders to a workspace from UI. In this settings file it lists added folders:

	"folders": [
		{
			"path": "C:\\Users\\user\\vscode\\test"
		},
		{
			"path": "C:\\Users\\user\\vscode\\ed"
		}
	],

Which seems sane enough, but the feature still seems to cause a lot of confusion (there are also optional? *.code-workspace files).

It seems like workspace settings are kept in .vscode/settings.json, which shows one advantage of the dot directory/file way: if you zip the root directory, you have all the project information there. This could of course be replaced by adding a project file on packing a project and reading it and passing settings into the central store on unpacking.

Besides Pygame Zero, web projects also have a defined structure. And projects could be one way to solve some issues that need to keep copies of files around or handle uncommon directory trees: #965, #945, #923, #724.

[aoloe]

personally, i tend to dislike hidden project files.

what about getting along without project files for the normal case (just adding the directory to a central config file like vs code does) and supporting a non-hidden, local, facultative, hand crafted, project file for the type of projects that can profit from it?

something like composer's composer.json, npm's package.json or dart/flutter's pubspec.yaml.

mu-editor could

• be able to create a skeleton, or
• completely manage the project file, or
• simply parse and use it

the project file would only be used when the user adds a directory as a project.

[dybber]

Would it be possible to use a minimal pyproject.toml?

On Tue, 29 Dec 2020 at 10.51, ale rimoldi ***@***.***> wrote: personally, i tend to dislike hidden project files. what about getting along without project files for the normal case (just adding the directory to a central config file like vs code does) and supporting a non-hidden, local, facultative, hand crafted, project file for the type of projects that can profit from it? something like composer's composer.json, npm's package.json or dart/flutter's pubspec.yaml. mu-editor could - be able to create a skeleton, or - completely manage the project file, or - simply parse and use it the project file would only be used when the user adds a directory as a project. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#659 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANPJENWTTBF2JIA6L3HYDSXGRAZANCNFSM4FWBXQEA> .

-- Martin Dybdal

[carlosperate]

To be honest, a lot of the project features described here feel a bit out of scope for Mu, which is meant to be a simple Python editor.
If you are a user that benefits from having a "project" you are probably ready to "graduate" to a more feature-full editor or IDE.

A few notes from my side:

• For modes like pygamezero and web it is true that we start adding folders that resemble a project structure
  • For pygame zero mode the "include this path magic" is done automatically by pygamezero, so Mu is only making sure that the folders are in the same directory than the python script (defaulting inside mu_code if the file isn't saved yet)
  • Similarly the web mode also adds the folders in the same directory if it doesn't exists
• Trying to automatically detect mode based on files and folders with very common names will eventually result in false positives.
• Adding a project file to the same directory where the python script is saved will be confusing for new users. I still struggle these days knowing what IDE files are useful or not, or what I can be deleted or I should keep.
• We can treat mu_code as an exception, but what happens when users keep multiple files in the same folder like with mu_code? I believe the feedback @ntoll got back when originally developing Mu is that users tent to drop everything in the same location (this is from memory, so I might be wrong).
• What is the main advantage of having "projects"? Is that to automatically recognise the right Mu mode? If that's the case I would consider that a different feature about remembering modes per file (which we could do with the Mu internal session.json file)

[devdanzin]

The hypothetical feature-set is still fuzzy to me, but I think projects would mean a simple way to create, send and receive a single file containing a (or a couple of) script(s), maybe templates and assets, probably describing the right mode. Mu would unpack it somewhere nice, allow adding material, editing, then packing it all to send back (or to someone else) if that's the goal. You could start a blank one to do some coding in an organized space, or turn a folder into one, or add new folders to an existing project. Then you could move back to a former project you were working on. Sounds like it could work well on guided environments, but maybe cause confusion for beginners learning alone/with less supervision.

I guess projects make sense to me because they would have helped me organize my sometimes presential, sometimes remote programming activities with my son. We started by emailing Python files, then zipped mu_code folders (which lead to some conflicts), now we're giving Google Drive a try. I must admit that we'll probably have a more streamlined, probably VCS-based workflow before we could make use of any project support in Mu. But that's how I'd be using the feature right now.

All that said, I'm not sure supporting projects at all is the right thing to do. Even if logical and slim, just the impact of more UI/workflow for complete beginners could be an impeditive. But, if we ever do, I think being explicit is a must (using pyproject.toml would be great for that). Having a simple, well-discussed set of features that fits Mu's scope would be the goal.

BTW, I was going to cite free-python-games as an example of something that could be sent as a Mu project: a collection of Python files that could be edited and sent back to a tutor. But it (as an installed package) can actually create copies of its own files for editing. So my would-be example actually shows that (at least part of) the we want might be implemented as an external tool.