search

mehcode / atom-project-plus

Simply awesome project management in Atom.
https://atom.io/packages/project-plus
MIT License
99 stars 19 forks source link

Call for Ideas / Discussion of how to move forward #36

Open mehcode opened 8 years ago

mehcode commented 8 years ago

What is missing from your workflow when dealing with projects in Atom? What is the pain point? I'd like to try to create a better project experience in Atom. The more :eyes: the better.

@shemerey @subesokun @jccguimaraes @danielbrodin @bripkens @vellerefond @Lixquid @prrrnd @danielmahon @t9md @crot4lus @guileen @chuckhendo @chocoelho @hokaccha @Ener-Getick

I mentioned everyone from a 2-page search that has worked on or is working on a project management-esque package in atom. The fact that I found this many is proof that we all feel that were all doing it wrong or not doing enough. I'd like to chat about this and figure out if we can pool our efforts into making one really good project package (instead of a few dozen packages that just confuses atom's user base). I think we all want the same thing here.

jccguimaraes commented 8 years ago

I'm up for this if we reach a reasonable quorum! :+1:

vellerefond commented 8 years ago

I agree, this is a very nice initiative.

On Thu, Mar 24, 2016 at 11:05 AM, Ryan Leckey notifications@github.com wrote:

What is missing from your workflow when dealing with projects in Atom? What is the pain point? I'd like to try to create a better project

experience in Atom. The more [image: :eyes:] the better.

@shemerey https://github.com/shemerey @subesokun https://github.com/subesokun @jccguimaraes https://github.com/jccguimaraes @danielbrodin https://github.com/danielbrodin @bripkens https://github.com/bripkens @vellerefond https://github.com/vellerefond @Lixquid https://github.com/Lixquid @prrrnd https://github.com/prrrnd @danielmahon https://github.com/danielmahon @t9md https://github.com/t9md @crot4lus https://github.com/crot4lus @guileen https://github.com/guileen @chuckhendo https://github.com/chuckhendo @chocoelho https://github.com/chocoelho @hokaccha https://github.com/hokaccha

@Ener-Getick https://github.com/Ener-Getick

I mentioned everyone from a 2-page search that has worked on or is working on a project management-esque package in atom. The fact that I found this many is proof that we all feel that were all doing it wrong or not doing enough. I'd like to chat about this and figure out if we can pool our efforts into making one really good project package (instead of a few dozen packages that just confuses atom's user base). I think we all want the same thing here.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/mehcode/atom-project-plus/issues/36

shemerey commented 8 years ago

One of the missing feature is project root detection, it's bother me all the time when I work on a project and [accidental/by purpose] open a sub directory of this project, but in 99% I do care about project folder only if it has .git

chuckhendo commented 8 years ago

For me, the reason I created Project Quick Open was because I don't believe there were any other project packages for Atom at the time (or there were and they just didn't meet my needs, can't remember).

The primary thing that differentiates PQO from other packages I've seen is that it doesn't try to do anything complicated with storing projects in a JSON file or having additional settings; it just opens folders that are inside other folders.

I was working on a rewrite, but I'd be happy to throw my support behind another project if it meets my needs. At first glance, this project seems to.

mehcode commented 8 years ago

The primary thing that project-plus was started to solve was project switching in-window. No package seemed to have a good solution as Atom (before 1.4 I want to say) used to be very tightly bound with its initial loadSettings (which were encoded in the querystring of the webview). Atom as of 1.7 can switch projects in-window with 2 lines. There are some glitches as other packages don't support it all the way so I added work-arounds. And there are shims to support Atom < 1.7.

What does a project package try / need to solve?

Project Discovery

Project plus currently supports:

Ideas to enhance discovery:

Project Open / Switch

Project plus currently supports:

I can't think of another idea or use case here. Not there isn't one so feel free to shout.

Project Configuration

I don't see how we can do this cleanly without implementing this in Atom itself. But I feel we should try to get that in as its something related to projects. In this project we could provide a means to edit/save project settings once Atom supports it.

Let's talk about what this project should do so that it can support as many of our use cases as we can. I'm thinking we all want near the same thing.

For instance,

The primary thing that differentiates PQO from other packages I've seen is that it doesn't try to do anything complicated with storing projects in a JSON file or having additional settings; it just opens folders that are inside other folders.

This can be solved with an extensive mechanism for discovery. Rather than forcing a all-projects-in-one-folder layout we can discover projects. I think what you want to avoid is that configuration step.

chuckhendo commented 8 years ago

Exactly. And this is already really, really close to what I want... closer to what I want than the current version of PQO actually. I'm going to use this for the next 24 hours or so, and if I'm still liking everything, I'll deprecate PQO and point it's users here.

I would like the ability to disable that discovery though, if needed. I often times end up working on... strange folder structures. I think I like the autodiscovery, but it doesn't seem like it would hurt to add an option to disable it so that it would behave more like PQO

mehcode commented 8 years ago

I would like the ability to disable that discovery though, if needed. I often times end up working on... strange folder structures. I think I like the autodiscovery, but it doesn't seem like it would hurt to add an option to disable it so that it would behave more like PQO

First, install master. It has a ton of changes not released yet as we're finalizing them.

We have two things to help there. There is a "Project Home" option that will limit the scope of discovery. There is also a checkbox to disable auto discovery.

chocoelho commented 8 years ago

I'll give it a try. I've read this package description and it covers pretty much project-switcher functionality.

I'm gonna use it for the next week and maybe deprecate project-switcher2.

Great initiative! I'm willing to help anyway I can.

On 03/24/2016 10:20 PM, Ryan Leckey wrote:

I would like the ability to disable that discovery though, if
needed. I often times end up working on... strange folder
structures. I think I like the autodiscovery, but it doesn't seem
like it would hurt to add an option to disable it so that it would
behave more like PQO

First, install master. It has a ton of changes not released yet as we're finalizing them.

We have two things to help there. There is a "Project Home" option that will limit the scope of discovery. There is also a checkbox to disable auto discovery.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/mehcode/atom-project-plus/issues/36#issuecomment-201094867

danielbrodin commented 8 years ago

Well, the Project Manager package that I believe was the first project manager package available provides the functionality that I need + some more. The only thing missing have been opening a project in the same window, and that have not been available until now with the solution that you have provided. Every other package have done it wrong, hence why I haven't included it. As you know and have suggested I have started to implement your solution into the Project Manager package, but there still seems to be some bugs in the coffee script to javascript implementation.

I rewrote the Project Manager some time ago to try make it easier for others to do PR and implement other features by separating a lot of the functionality like the database which would more easily make it possible to for example implement your solution of providing projects from the state store instead of my projects.cson by just adding a setting and a new type of database. Of course some other work could be needed, but as everyone knows it's not easy to code a project like that at once by yourself, you need some input to get it right.

Not to be rude, but I get the feeling that somehow most people that have created some sort of project manager have found the Project Manager package and found something missing, so they have made their own project manager package instead of contributing to an existing one. In many cases it seems to have been the project switching part, but as I said before, it have been done completely wrong in all cases before @mehcode solution. I'm not saying I have the perfect solution, but I haven't got any PR that handles anything that the other packages provide, except for @mehcode old project switch hack that from what I recall you didn't really recommend yourself and it broke pretty quick since atom was in an early beta.

So I'm all up for suggestions and discussions.

And again, I really do not mean to be rude, but that is really the impression I have about most other project manager packages I have found (which probably isn't all). And this adds to many other packages to of course. I only started the Project Manager package because there wasn't anything like it and it was something I really needed to be able to switch to Atom.

So getting a PR that would solve for example the project switching part would make both my day, and many of the users of my package day I'm sure.

chuckhendo commented 8 years ago

I think a lot of users are intimidated by making PRs, and it's easier to mess around with stuff in their own little sandbox. This isn't necessarily the RIGHT attitude to have, but it's something I've seen a lot of. Other times I think it's a difference of philosophy in how the core functionality of the package should work that leads to alternatives being developed.

As for my package (https://github.com/chuckhendo/project-quick-open/), I submitted it pretty early in the days of Atom package development. In fact, @danielbrodin, it's a pretty interesting coincidence that you and I released our first versions (0.1.0) on the same day (Mar 19 2014). The primary problem with my package has been a lack of time to dedicate to working on it up until recently, and then I come across this!

Admittedly, I haven't spent a ton of time using Project Manager, but it always felt a bit too cumbersome for my needs with the requirement of setting projects up in the project.cson file (please correct me if I'm wrong @danielbrodin). The core philosophy behind project-quick-open was to allow you quickly choose from a list of folders inside of another folder, and that was it. It might have been more appropriately named "folder-quick-open" because it didn't handle any other project code. So I've continued to use project-quick-open for my own needs, despite the fact that I badly need to update it and many things (such as the open in same window functionality) are done in the "wrong" way. That's up until I started using this package last night.

I don't necessarily think we need 1 package, as a single package can't possibly meet the needs of every user. Especially with something like "project opening," which is a personal to each users workflow. This package is pretty close to suiting my needs, and already seems to be able to replace PQO for me.

mehcode commented 8 years ago

I started this project as a fork of project manager. I had one idea after another and split off. I was going to try to merge back but I reached a number of features that I felt at the time would be hard to push into an existing codebase as long lived as project manager. @danielbrodin Nothing against your package but sometimes it takes a new / clean codebase to spike a new / radical idea (in this case it was the auto discovery I was excited about).

I don't necessarily think we need 1 package, as a single package can't possibly meet the needs of every user.

I feel that something like package management can get really close (hit the 99%) with smart configuration. The 2 big reasons I saw people drifting from project manager is the switcher and manually saving projects.

@danielbrodin I'd love to collaborate on this package with you and help make it the best it can be. I've nothing against your codebase but like I stated earlier, sometimes a clean / fresh start is needed for a radical idea. This package now is nearly a superset of yours (as I added support for projects.cson the other day).

However.. in the strict interest of collaboration I extracted the project switching functionality to https://github.com/mehcode/atom-project-switch -- there are still a number of rough edge cases that are solved there. As bugs appear I'd rather fix them in one place (if there are going to be more than 1 project package going forward).

GuilhemN commented 8 years ago

Thanks for this initiative but I'm not sure that's a bad thing to have several packages doing project management. For example recent-projects discover new projects only when you open them (this may be painful at the beginning but it is much better for me after some time as you can choose exactly which folder to save). I also prefer a tab instead of a popup (I don't like them much). BTW actually I like to be able to open projects in new windows so I don't think you should force people to use the same window.

And finally, I don't know if this is done in your package, but I think that projects should be sorted by last opening.

I hope this will help you :-)

mehcode commented 8 years ago

@Ener-Getick Big picture here. Project management is only slightly different for everyone. I fully believe we can cover the 99% here. Let me go over your points.

For example recent-projects discover new projects only when you open them [...]

This does that with the auto discover option turned on (which it is by default).

I also prefer a tab instead of a popup (I don't like them much).

A toggle-able tab/panel/etc. would be a perfect addition to this package. I'd accept a PR here.

BTW actually I like to be able to open projects in new windows so I don't think you should force people to use the same window.

This isn't super clear in the readme but shift-enter will open the project in a new window. This hasn't been suggested yet here but I wouldn't mind a config option to invert the commands. Eg. enter is new window and shift-enter is same window.

And finally, I don't know if this is done in your package, but I think that projects should be sorted by last opening.

This is done in this project. This project even has magical tab switching (that works near identical to alt-tab in your OS).

ghost commented 8 years ago

Hello, I'd like to chip in on the "project configuration" bit as it hasn't been touched much yet. I'll try to keep the information as short as possible but there unfortunately is a lot to mention, please excuse my wall of text ;-).

Who am I?

I maintain the php-integrator-* packages, which in short words index a project and do various things with its information (such as autocompletion, tooltips, ...). We've now reached a point where it would be interesting to implement things such as excluding certain folders from the indexing process and passing project-specific hints to the indexer.

The problem

We need some way to fetch information about the active workspace. This involves simple things such as: what root folders are part of the project, but it also involves more complex things such as "what folders does the user wish to exclude from the indexing process?".

It seems to me that Atom has a notion of "projects", but it has no notion of "project types". For example, my web application could be a PHP project as well as a JavaScript project. A PHP project could be working with PHPCS, PHPMD, the Padawan autocompletion server, etc. The JavaScript part of the project could have completely different needs.

A good example of a problem that arises with this is the current behavior of my base package: it blindly starts trying to index every combination of root folders that appear. This happens because there is no way for me to detect whether the current "combination of root folders" will in fact contain PHP code. Even if it does, the user might not want me to index it or, if it doesn't, the user might still want me to index it as he will provide the code in the future.

How is this problem solved? The most convenient way is for the user to indicate that the current project is a PHP project by some means. IIRC, the TypeScript package did just that by looking for a file called tsconfig.json. I could do the same thing and introduce a project file, but this seems wrong: every other somewhat complex package that has some kind of configuration needs will start introducing a custom config file. This will leave the user with an array of these files. What's worse, these files could all be in different formats and some may have some kind of interface to manage them, others may not. Also, this project is still the same project, why can it not be described by a single file?

A better solution?

The better solution is probably to have some kind of central package that manages this. The problem here is that, much like has happened for project management packages: who is going to develop this package? Can we have some kind of guarantee that it will be maintained? If I delegate project management to a third party package, I will have to create a dependency on it, or the feature set for my users will be severely limited without it. Also, I do not intend to maintain multiple ways of managing project settings, as that kind of defeats the purpose.

As @mehcode already hinted, a good solution would be to have the configuration of project settings in core Atom or an official Atom package. This guarantees that it:

Interesting possibilities

With a central project management tool, you can do all kinds of interesting things:

[1] https://github.com/Gert-dev/php-integrator-base/issues/86

danielbayley commented 8 years ago

I wouldn't mind a config option to invert the commands. Eg. enter is new window and shift-enter is same window.

@Ener-Getick @mehcode See #46. 👍

danielbayley commented 8 years ago

Personally I would like to see this and project-manager merged. They are very close now, with only minor differences. This one functions better, while project-manager feels more polished.

I think movement towards a local project.cson rather than the global projects.cson (which should maybe be phased out?) is the right way to go. Also, optionally .project.cson or even JSON for the CoffeeScript haters out there (I'm definitely not one of them)… Maybe it could additionally be configured inside package.json for that matter; with a "project-plus": object or something.

Options like icon: and devMode: are nice, with their accompanying icons showing up in the modal which this package doesn't do.

Maybe you could even have an option in package settings to filter out projects that don't contain a local project configuration or something.

It would also be nice if we could clear projects from the database/cache, or revert back to only 'saved' projects.

Anyway I'd be happy to help out if some decisions can be agreed.

mehcode commented 8 years ago

I think movement towards a local project.cson rather than the global projects.cson [...]

I see a couple issues. The projects.cson file serves as a marker that lists "saved" projects (to be picked up instead of just looking for projects without auto discovery). Second is that a project can have one or more folders, how would that look? Which folder would have the local project.cson? One more is that several people don't care for editor/ide files in the git repo so it'd be once more thing in .gitignore. I'm not opposed to the idea, we just need to talk it out.

Options like icon: and devMode: are nice [...]

We'd definitely accept PRs that implemented these. What should the behavior be if you "switch" to a project that requests dev mode? Reload the window in dev mode? Is that possible?

Maybe you could even have an option in package settings to filter out projects that don't contain a local project configuration or something. It would also be nice if we could clear projects from the database/cache, or revert back to only 'saved' projects.

As #41 explains, there is a bug with disabling the auto-discover. Atom <1.7 stored project state in files in $HOME/.atom/storage. These files are added to the project switcher regardless of the auto-discover setting. As project state is no longer stored in there, doing rm $HOME/.atom/storage/editor-* is harmless and will fix your issue. If I find time I'll fix the :bug: as well.

Anyway I'd be happy to help out if some decisions can be agreed.

We appreciate the contribution you've already made and I'd love the help. Thank you.

ghost commented 8 years ago

Second is that a project can have one or more folders, how would that look? Which folder would have the local project.cson? One more is that several people don't care for editor/ide files in the git repo so it'd be once more thing in .gitignore. I'm not opposed to the idea, we just need to talk it out.

I realize now that usually you don't use multiple root folders to actually have multiple folders of the same project open at the same time, you rather have multiple projects open at the same time. For example, suppose you have an XMPP client and server, which are two seperate projects (and hence have two different folders in the file browser), but you may still want to visually have them open at the same time (hence two root folders in the same workspace) as they are closely related. However, they are still both separate projects. It seems to me that you usually group folders belonging to one project under a common root folder. In this case, the answer to the question is: all of them can or will have a project.cson file.

I also commonly see project files being ignored in Git. However, there are cases where it can be beneficial to include them. For example, C++ projects may include compiler and linker arguments needed to build the project. You'd also want to share this information with colleagues or contributors. IIRC, Visual Studio uses a separate file for user-specific configuration and the actual project file that contains the shared settings.