Poor error before configuration

[ftrotter]

Hey, When we have an existing composer.json file with requirements for zermelo et al... Then basically all of the "composer require" commands have already been run when we do the very first composer install on a project.

Next we should run the commands

php artisan install:zermelo php artisan install:zermelobladetabular mkdir app/Reports

But if we have not done that and we visit an initially configured laravel instance (with zermelo required) then we get the following strange error:

The prefix / is taken and can't be used in CareSet\ZermeloBladeCard\Controllers\SummaryController. This error may be caused because the configuration file for this controller is not being properly read and the correct prefix is not being loaded

That is a shitty and confusing user experience that should say, basically..

"hey you need to run the rest of your zermelo installation to get the default config files"

Or some such.

[tmccormi]

There is a bit of a conflict in terms of "user level" that I am dealing with. The assumption right now is that the user is an experienced Laravel developer that understands a lot about the standard models for laravel and composer driven projects.

I'm not that guy (which is good) I would like to drive the whole process down a level or two to actually support developers that have never used laravel or composer at all ... that might be a stretch at first, but I think it can be done.

[ftrotter]

There are three types of users that we need to respect here:

• First is experienced php developers who choose to deploy this as the reporting engine of choice for their team
• Second are report writers (most people call them data scientists now) who understand SQL, but are not famliar with the internal workings of php. The whole point of this project is to make their lives easier
• Third are the report consumers, the end users who will be looking at the reports in the end.

We need to have good errors precisely because the people who are working with our systems are going to frequently be people who are NOT experts in php. There are dozens of design decisions that are made with this user in mind. This is the reason for the "everything in one file" approach. This is the reason for the focus on having decisions made in SQL, and everything else just works around those decisions.

So when we evaluate whether we are going to be putting more effort into a better error message, we need to wonder: "Will a data scientist who really wishes she was working in SAS, R or Python every going to see this error" and it the answer is "Yes" or "Maybe" then we need to ensure that the error message clearly says "Your likely forgot to do X" rather than something else that is something a "php expert would recognize".

-FT