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

Framework detection out of scope? #9

Open
rask opened this issue Jun 17, 2015 · 7 comments
Open

Framework detection out of scope? #9

rask opened this issue Jun 17, 2015 · 7 comments
Labels

Comments

@rask
Copy link

rask commented Jun 17, 2015

I was wondering whether adding feature checks for things like "running on Laravel" or "running on WordPress" are out of scope for the library?

E.g.

if (Morse::featureExists('framework/laravel') {
    ...
} elseif (Morse::featureExists('cms/wordpress') {
    ...
} else {
    ...
}
@rask rask changed the title Non-PHP-core feature detection out of scope? Framework detection out of scope? Jun 17, 2015
@drewm
Copy link
Owner

drewm commented Jun 17, 2015

That's an interesting idea. What sort of projects need that ability?

@telephone
Copy link

I can't really think of a proper use for this feature. Dependencies should be handled by Composer, and if a dependency is missing, it'll be obvious via the error message/s

Now an interesting take on this would be checking if framework specific helpers exist (non-namespaced functions). For example, Laravel Helpers or Wordpress functions. In saying that though, I still believe this should be handled by Composer as it deals with dependencies instead of cross-platform environments.

@drewm
Copy link
Owner

drewm commented Jun 17, 2015

One of the big benefits of Morse is dealing with situations where you aren't in control of the dependancies. e.g. if you know that your code will often be used with WordPress, and if so, you can call out to some WP function to make life easier.

So I'm interested in this - I'm just not sure if this is a theoretical problem or a real problem to solve.

@drewm
Copy link
Owner

drewm commented Jun 17, 2015

Here's a potential real-world usage example:

https://github.com/michelf/php-markdown/blob/master-stable/markdown.php#L70

@telephone
Copy link

@drewm How would you handle version comparison (new functions in v4 versus v5)? Or would you just have a broad check, and leave version comparison to the user?

For frameworks that are decoupled like Laravel, how would you check if one package is installed (such as 'illuminate/database') versus the whole framework?

(Laravel isn't the best example of a decoupled framework 😏).

@drewm
Copy link
Owner

drewm commented Jun 17, 2015

Valid question.

@rask
Copy link
Author

rask commented Jun 17, 2015

@telephone

I can't really think of a proper use for this feature. Dependencies should be handled by Composer, and if a dependency is missing, it'll be obvious via the error message/s"

Good point.

Regarding individual packages: as far as I know PHP doesn't provide any means for validating namespace existance. Checking a known class inside a package could work, but there's no knowing when the package author decides to remove the class.

Or perhaps validate that the composer.json file exists in the vendor/author/package directory (this would be safest with using the Composer style author/package naming convention for checks)? Can the vendor directory name be defined by Composer users themselves?

@drewm drewm added the question label Jun 17, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants