Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed Plugin Task to deny option of ROOT/plugins and fixed Autoloading Generation #26

Merged
merged 10 commits into from Jan 18, 2015

Conversation

DSchalla
Copy link
Contributor

PR related to the change: cakephp/app#206

The first commit is filtering the ROOT/plugins path from the options and exits with an error if no other path is available, I am unsure if exit; was the correct choice in a Shell Task, I would like to get some feedback regarding that.

The second commit fixed the Autoloading Generation to allow other than the default path options to be used as plugin path, the chdir adaption was required since the old version could not deal with anything but the first child of ROOT.

Any comments are appreciated.

@DSchalla
Copy link
Contributor Author

I am unsure how to handle the test failures, could it be that the ROOT constant is not defined in the Tests which lead to the failure? Is the usage of the ROOT variable not fine or do I simply have to rename the paths in the testcases?

@dakota
Copy link
Member

dakota commented Jan 10, 2015

I don't think it's a good idea to deny baking of plugins into ROOT/plugins. I often create plugins with bake which I then publish via packagist or a local satis install.

I don't see what's wrong with baking plugins into ROOT/plugins?

@DSchalla
Copy link
Contributor Author

@dakota Did you read the PR linked at top?

@dakota
Copy link
Member

dakota commented Jan 10, 2015

I did, I still don't think it's a good idea blocking baking into ROOT/plugins. Perhaps giving a warning would be the solution?

@DSchalla
Copy link
Contributor Author

A warning or maybe a option flag could be used, like --composer or something like that.

@ADmad
Copy link
Member

ADmad commented Jan 10, 2015

I often create plugins with bake which I then publish via packagist or a local satis install.

@dakota IMHO you should maintain separate folders for developing / publishing and using in an app.

@dakota
Copy link
Member

dakota commented Jan 10, 2015

@ADmad you're right, I'm just being lazy :)

@jadb
Copy link
Contributor

jadb commented Jan 10, 2015

@dakota you can still be lazy, this PR won't stop you ;)

And to suit your laziness, here's the new path ready for you to copy/paste:

cd src/Plugin

@markstory
Copy link
Member

I don't think preventing people from putting code where they want is a good idea. What if there was an output-dir option that defaulted to the new path? This would let people output plugin skeletons for standalone plugins as well.

@lorenzo
Copy link
Member

lorenzo commented Jan 10, 2015

I like that idea @markstory

@DSchalla
Copy link
Contributor Author

Then we can just remove the filter again and the app.default.php has to be adapted, since this controls how the paths are ordered when multiple exist. Or did I misunderstood something?

@lorenzo, any hints regarding the tests?

@@ -235,7 +237,7 @@ protected function _modifyAutoloader($plugin, $path)
$cwd = getcwd();

// Windows makes running multiple commands at once hard.
chdir(dirname($path));
chdir(ROOT);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why did this change?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks to be logically correct to make this change; dirname($path) means dirname('plugins/)` - it's implicitly assuming the plugins dir is one level below the root.

However, I'd rather it was:

$file = $this->_rootComposerFilePath(); # <-
...
chdir(dirname($file));

There's no need to use a constant.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, the changes was related to that issue. Regarding _rootComposerFilePath(), that would be an unnecessary function call since the function is also just:
"return ROOT . DS . 'composer.json';"

However, if requested I can ofc change it to use the function call. In your snippet, dirname($file) is sufficient, since we do not want to step out of the root, hu?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please consider testing - you don't want to be modifying ROOT . DS . 'composer.json when tests run and that's why it's in a separate function (and why generally I purged constants from the code recently).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's totally fine, I will update the code to use the function tomorrow. Thanks for your advice @AD7six

@DSchalla
Copy link
Contributor Author

When using a different path than ROOT/plugins you would not switch back correct to the root folder. As example, ROOT/src/Plugin would switch back to ROOT/src, leading to a failure for the composer call.

@josegonzalez
Copy link
Member

@lorenzo bump

}
},
"autoload-dev": {
"psr-4": {
"ComposerExample\\Test\\": "./plugins/ComposerExample/tests"
"ComposerExample\\Test\\": "/tmp/tests/BakedPlugins/ComposerExample/tests"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Paths should be relative as when you deploy the path will probably not be the same.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The path used above is related to the fact that the plugin path in the Test Instance is set to /tmp/tests/BakedPlugins, on a productive environment it would look like:
'"Test6\Test": "./src/Plugin/Test6/tests"

@lorenzo
Copy link
Member

lorenzo commented Jan 15, 2015

Thanks a lot for the effort @DSchalla, the team decided to go another way with this. Instead of disallowing baked plugins in ROOT, we decided to put them only there and have composer install plugins in vendors. That way there will be a clear separation between both, all thrid-party libraries will be in the same place and no gitignore will be required for in-app plugins.

I'm sorry you had to work on this and not get this merged, you win 100 internets from me 💪

@lorenzo lorenzo closed this Jan 15, 2015
@lorenzo
Copy link
Member

lorenzo commented Jan 15, 2015

Reopening as this PR was transformed to fix a couple limitations on how plugins are baked. The problem in tests still need to be solved

@lorenzo lorenzo reopened this Jan 15, 2015
@markstory markstory added this to the 1.0.0 milestone Jan 15, 2015
@DSchalla
Copy link
Contributor Author

@markstory markstory self-assigned this Jan 16, 2015
@markstory markstory merged commit 475d5f3 into cakephp:master Jan 18, 2015
markstory added a commit that referenced this pull request Jan 18, 2015
…neration

Merge branch 'DSchalla/master' into master.

Closes #26
@markstory
Copy link
Member

Thanks 👍

@DSchalla
Copy link
Contributor Author

Thanks @markstory for the merge!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants