Open yajo opened 4 years ago
Ok, could you elaborate more on this? You basically want to have some sort of extra fields in a workspace? or just be able to share the workspace? I'm asking that because it kind of makes sense, but for example to launch your editor with the path to the code is not the same for everyone, so that wouldn't be useful.
Do you have any idea?
Regarding path can be done in this way:
Humm true.
Also maybe some people want to use one terminal, editor or browser, and some people others...
There could be a place where to configure your favourite apps for such common scenarios. Or to define some variables that indicate the root of your dev folders. Then the shared template could use those variables to present a shared configuration for all users within a team, without forcing emacs users to use vim or viceversa.
browser , terminal etc are the default ones in your system. We could make a base path in a project and then the commands are going to be executed from that directory.
defaults can be interesting for a workspace, we have to think as well design wise how we could implement that. And then once that is figured out we could make an import and export function
Humm yes.
The point is that imagine one service moves from one domain to another... Then all devs in the team just open workspaces, sync it with the team config, and then when opening the website, it opens the correct domain and not the old one.
Just an example, you know? Something like project settings working out of the box for everybody.
I guess the complicated part is that maybe somebody would still want to add some item just for their computer, but well... They can always use a separate project for those items after all...
Hi. This seems like a great idea. IMHO, a good way to do it would be following the same principle as, for example, VSCode, where you can have global settings set up by the user (these could be paths for the appropriate binaries, which editor to use, etc.) and then project specific settings (like server locations, domains, etc.), which could be shared by the team. A good way to enable syncing would be to simply allow to define settings with some sort of file (YAML, for example) and then we can sync those with an external tool (like git, syncthing, etc.)
Those are great ideas. But seems like the tool would get way more complex than it is. In a project we could add variables which are then usable in commands.
On Sat, Sep 19, 2020, 8:54 AM João Marques notifications@github.com wrote:
Hi. This seems like a great idea. IMHO, a good way to do it would be following the same principle as, for example, VSCode, where you can have global settings set up by the user (these could be paths for the appropriate binaries, which editor to use, etc.) and then project specific settings (like server locations, domains, etc.), which could be shared by the team. A good way to enable syncing would be to simply allow to define settings with some sort of file (YAML, for example) and then we can sync those with an external tool (like git, syncthing, etc.)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/DevAlien/workspaces/issues/39#issuecomment-695174770, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABQ476ROBXGTBN7VHGSWGDSGRIT7ANCNFSM4RMV37WA .
It seems a nice enhancement too.
Of course, we're just sharing ideas, don't feel guilty if any of them falls out of scope of what you think the project is 😉
Of course, but I want to find a solution that works for most people, without making it too complex
I'm thinking that after all you have to store configurations somewhere, right? If you let the user to specify one or several places, he can choose any tool he wants to sync just one of those. That'd be the simplest fix I think.
I see this could be a great way to work, and I'd like to consider including it in our dev workflow toolbelt.
It would be very nice if there'd be a way to share definitions, something like a git repo would be awesome. This way, devs in the team could share some specifics of the projects, such as where the git code exists, what's the project URL, how to connect to the server via SSH, and so on.
Of course, being able to include custom items in a project, or custom projects, that wouldn't be shared would be just perfect.