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

Turn into Composer package #28

Closed
Rarst opened this issue May 27, 2013 · 15 comments
Closed

Turn into Composer package #28

Rarst opened this issue May 27, 2013 · 15 comments

Comments

@Rarst
Copy link
Contributor

@Rarst Rarst commented May 27, 2013

In my opinion scbFramework would fit very well as Composer package:

  • it's meant to be used as library and version control submodules are pain
  • it's purely classes, so it's well suited for autoload
  • if shared between plugins (whole site stack), issue of versioning and loader simply goes away (hm, ok versioning goes away, still need loader for backwards compat and executing callbacks)

Con:

  • will need to switch to semantic versioning
@scribu
Copy link
Owner

@scribu scribu commented May 27, 2013

if shared between plugins (whole site stack), issue of versioning and loader simply goes away (hm, ok versioning goes away, still need loader for backwards compat and executing callbacks)

There's already a loader meant for mu-plugins usage, but it's in a separate repo:

https://github.com/scribu/wp-scb-framework-example/blob/master/scb-load.php

@scribu
Copy link
Owner

@scribu scribu commented May 27, 2013

Question: in a WP install, where do you load Composer's autoload.php file from?

@Rarst
Copy link
Contributor Author

@Rarst Rarst commented May 27, 2013

Makes sense for shared usage (won't need includes, just scb_init() like pluggable to simply run callback). Maybe mandate that autoload includes that version of scb_init() and use loader version if not using autoload?

Question: in a WP install, where do you load Composer's îautoload.php` file from?

That's... uhm... undecided. :) My current practice - plugin check for autoload in its folder and uses it if present.

if ( file_exists( __DIR__ . '/vendor/autoload.php' ) )
        require __DIR__ . '/vendor/autoload.php';

If not present it is assumed that autoload is on project level and something else takes care of it.

However since there is no official support or widespread usage of Composer for WP - there is not yet convention of how to include autoload in whole-site stack. My best guess is in wp-config.php so it's working as early as being available to mu-plugins.

@scribu
Copy link
Owner

@scribu scribu commented May 27, 2013

Maybe mandate that autoload includes that version of scb_init() and use loader version if not using autoload?

Yes, you'd basically need to copy the scb-load.php file into this repo and add it to the mix:

"autoload": {
  "files": ["autoload.php"]
}
@scribu
Copy link
Owner

@scribu scribu commented May 27, 2013

Or maybe load-mu.php would be a better name than autoload.php.

@Rarst
Copy link
Contributor Author

@Rarst Rarst commented May 27, 2013

mu is confusing since it's not actually in mu-plugins in that case. I was thinking functions-autoload.php which seems descriptive as it will provide function definition, but only for autoload use context.

I will start on it and look if anything else sticks out and will pull request later.

@Rarst
Copy link
Contributor Author

@Rarst Rarst commented May 27, 2013

Files done. What about versioning? Or keep r* and only have dev package version?

@scribu
Copy link
Owner

@scribu scribu commented May 27, 2013

Yeah, only dev version; as with WordPress Core, eternal backwards compatibility is the law.

@Rarst
Copy link
Contributor Author

@Rarst Rarst commented May 27, 2013

Okies, although might revisit later if dev-only causes hiccups in practice. I have plugin on it (in eternal development) will refactor to Composer later and see how it ticks.

@scribu
Copy link
Owner

@scribu scribu commented May 27, 2013

I think you'll find that it's broken. The class names start with 'scb', but the file names don't, so I'm pretty sure the Composer autoloader won't find them.

@Rarst
Copy link
Contributor Author

@Rarst Rarst commented May 27, 2013

Tried or thinking? Should work just fine, classmap autoload type scans files content on install and is precisely for handling arbitrary naming conventions.

@scribu
Copy link
Owner

@scribu scribu commented May 27, 2013

Was about to try. It's great that Composer can do a static analysis like that.

There's one more hitch: Utils.php contains some standalone functions.

@Rarst
Copy link
Contributor Author

@Rarst Rarst commented May 27, 2013

Composer is all kinds of magical. :)

Path of least resistance would be to throw it into files array for explicit include.

@scribu
Copy link
Owner

@scribu scribu commented May 27, 2013

Good idea; done.

scribu added a commit that referenced this issue May 28, 2013
@scribu
Copy link
Owner

@scribu scribu commented May 28, 2013

Tested it; seems to work fine.

scribu added a commit that referenced this issue Jun 5, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

2 participants
You can’t perform that action at this time.