Composer, Linter, & The Marketplace
Permalink
Hello,
I have kind of a unique situation. I'm in the process of porting Backup Pro to Concrete5 and I recently learned there's a Linter available to validate the code for inclusion into the marketplace. Inclusion into the marketplace is VERY important to me, since Backup Pro for Concrete5 is very much being built for commercial release, so I ran my work in progress through it just to see what would happen.
Obviously, not being close to done, it failed. Spectacularly. Not unexpected, but what it failed on was. Looks like the Linter goes after all the included Composer and Backup Pro core libraries as well. And there are LOTS of issues with those. I've followed the instructions located in the docs (and below) to get the autoload and path worked out so not quite sure what the issue is.
http://documentation.concrete5.org/developers/packages/advanced-inc...
Any suggestions? Is this something I need to worry about or just a known issue with the Linter? Are issues with Packages and the Linter cause for exclusion from the marketplace?
Thanks,
Eric
I have kind of a unique situation. I'm in the process of porting Backup Pro to Concrete5 and I recently learned there's a Linter available to validate the code for inclusion into the marketplace. Inclusion into the marketplace is VERY important to me, since Backup Pro for Concrete5 is very much being built for commercial release, so I ran my work in progress through it just to see what would happen.
Obviously, not being close to done, it failed. Spectacularly. Not unexpected, but what it failed on was. Looks like the Linter goes after all the included Composer and Backup Pro core libraries as well. And there are LOTS of issues with those. I've followed the instructions located in the docs (and below) to get the autoload and path worked out so not quite sure what the issue is.
http://documentation.concrete5.org/developers/packages/advanced-inc...
Any suggestions? Is this something I need to worry about or just a known issue with the Linter? Are issues with Packages and the Linter cause for exclusion from the marketplace?
Thanks,
Eric
Nice. I think that'll be workable.
The biggest concern is in how Backup Pro's been designed to be a backup program that integrates into a CMS instead of a backup program built FOR a CMS. So, outside of the controller/action scaffolding, all of the heavy work is passed into the core Backup Pro libraries, which are basically stand alone (after some minor bootstrapping).
If you're curious, I'd written about the details and some specifics:
https://mithra62.com/blog/view/backup-pro-3-has-landed...
https://mithra62.com/blog/view/going-platform-agnostic-or-beer-taste...
Key point though is that I don't rely on much of the core CMS for anything big. I do stick to your routing/bootstrapping, request control, and view handling though. I just have my own DI Container that the Package uses. So, basically, 90% of Backup Pro is a third party library (at least insofar as the design).
It absolutely works though. It's already out for 4 other CMS's (5 versions FWIW) who've exercised most of the bugs and issues (the suckers :)). I don't have 100% test coverage, yet, but it's getting there. Plus, Backup Pro kinda pays my bills at this point so it's only going to get better.
One last question if I can; do you see anything in the below requirements that jumps out at you as a reason it wouldn't be approved?
Curl available for PHP
Zip available for PHP
mysqli or PDO MySQL extension (Mysqli is used if both are present)
mbstring extension
PHP 5.4+
At least 30 MB of available disk space for the module (more depending on your setup and cache needs)
At least 200 MB of available disk space for backups
Thanks for your time.
The biggest concern is in how Backup Pro's been designed to be a backup program that integrates into a CMS instead of a backup program built FOR a CMS. So, outside of the controller/action scaffolding, all of the heavy work is passed into the core Backup Pro libraries, which are basically stand alone (after some minor bootstrapping).
If you're curious, I'd written about the details and some specifics:
https://mithra62.com/blog/view/backup-pro-3-has-landed...
https://mithra62.com/blog/view/going-platform-agnostic-or-beer-taste...
Key point though is that I don't rely on much of the core CMS for anything big. I do stick to your routing/bootstrapping, request control, and view handling though. I just have my own DI Container that the Package uses. So, basically, 90% of Backup Pro is a third party library (at least insofar as the design).
It absolutely works though. It's already out for 4 other CMS's (5 versions FWIW) who've exercised most of the bugs and issues (the suckers :)). I don't have 100% test coverage, yet, but it's getting there. Plus, Backup Pro kinda pays my bills at this point so it's only going to get better.
One last question if I can; do you see anything in the below requirements that jumps out at you as a reason it wouldn't be approved?
Curl available for PHP
Zip available for PHP
mysqli or PDO MySQL extension (Mysqli is used if both are present)
mbstring extension
PHP 5.4+
At least 30 MB of available disk space for the module (more depending on your setup and cache needs)
At least 200 MB of available disk space for backups
Thanks for your time.
If there are any prerequisites that may not be available on some sites, the important points are:
a) You detail the prerequisites and how to check for them on the marketplace page, so as to avoid (as much as possible) users purchasing something that won't work on their site
b) You test for the prerequisites on package installation, and refuse to install with appropriate messages if they are not met
c) In a situation where a prerequisite could have been met at installation, but may no longer be met, there are sufficient guards and checks that nothing breaks a site.
A c5.7 site should run on php5.3+. (A c5.6 site should run on php5.2+. ). Exceptions can be made when a vendor library has a higher dependency, but not for any c5 specific code which must work with the minimum version. This minimum version is likely to be higher when c5.8 is released.
a) You detail the prerequisites and how to check for them on the marketplace page, so as to avoid (as much as possible) users purchasing something that won't work on their site
b) You test for the prerequisites on package installation, and refuse to install with appropriate messages if they are not met
c) In a situation where a prerequisite could have been met at installation, but may no longer be met, there are sufficient guards and checks that nothing breaks a site.
A c5.7 site should run on php5.3+. (A c5.6 site should run on php5.2+. ). Exceptions can be made when a vendor library has a higher dependency, but not for any c5 specific code which must work with the minimum version. This minimum version is likely to be higher when c5.8 is released.
Very cool. Thanks for the insight.
- It needs to work
- you need to justify all exceptions
- exceptions will usually be granted for third party libraries
- you need to make an exceedingly good case for any code that is not in a third party library. If there is a c5 way to do it, we expect non third-party code to conform.