Skip to content
This repository has been archived by the owner on Apr 6, 2021. It is now read-only.

Remove Limitation of Single Project Type #5

Closed
nathankleyn opened this issue Mar 17, 2015 · 1 comment
Closed

Remove Limitation of Single Project Type #5

nathankleyn opened this issue Mar 17, 2015 · 1 comment
Assignees
@nathankleyn
Labels
enhancement

Comments

@nathankleyn
Copy link
Contributor

I was discussing with @janstenpickle about how the limitation of only being able to have a single type for a project is an issue:

  • Some projects mix scripts and an application in the same dir: think Gemfile in the root of a Rails app.
  • We currently have a bit of a hacky solution to ensure the right type gets picked by using numerical priorities.

In addition, the default project type is StaticProject which isn't actually a good idea:

  • This causes a tar.gz to get built when you probably don't want one.
  • It's very hard to make that sort of logic work for everybody and it may not belong in the core but rather as a plugin.

What we kind of want instead is a sort of IdentityProject, where the project has no type and instead all functionality is implemented as traits (or in Ruby language, mixins). We already have the ability to do exactly this with plugins and the base Project class!

So here's what I'm going to implement (with buy-in from @janstenpickle):

  • Remove the notion of project types. All project will be instances of Project.
  • Remove ProjectTemplate. Now we don't need to worry about setting the type from Shantyfile files, we can just create ProjectTemplate instances immediately and mutate their attributes from the Shantyfile instead.
  • Doesn't really make sense to have Discoverers anymore, might as well just have something a plugin can define that says what directories should become projects. This is especially true now that all the discoverers are being used for nowadays is to find projects to add types/plugins to.
  • That leaves Mutators looking a bit sad in the corner by themselves - well, might as well make them a plugin as well. That makes me very happy as then, the only linguistic notion we have invented is "plugin", and I dare say that's quite well understood already!
@nathankleyn nathankleyn self-assigned this Mar 17, 2015
nathankleyn added a commit that referenced this issue Mar 19, 2015
@nathankleyn
Remove the notion of a project type.
6e4407c 
Rather than a "type" of a project, plugins start to emerge as the "one
true way™" of doing everything. We will have a single project class, and
one would mix in plugins to add the needed functionality. There are some
new methods on the graph to find projects with a given plugin, replacing
the old `all_by_type` and `changed_by_type`: these new methods are
`all_with_plugin` and `changed_with_plugin`, respectively.

This work is in regards to #5.#5.#5.
@nathankleyn
Copy link
Contributor Author

All done with this now, and the code is in master.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@nathankleyn nathankleyn

Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@nathankleyn