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

Refactor sake around Symfony console #11341

Closed
3 tasks done
emteknetnz opened this issue Aug 18, 2024 · 17 comments
Closed
3 tasks done

Refactor sake around Symfony console #11341

emteknetnz opened this issue Aug 18, 2024 · 17 comments

Comments

@emteknetnz
Copy link
Member

emteknetnz commented Aug 18, 2024

sake is basic though functional way to run cli commands

It's very non-standard, and it's likely that we could make the interface significantly better by changing it to use symfony/console instead. There may also be some downstream benefits of making it easier to project to extend/customise if they have a need to

Related

Acceptance criteria

  • First determine if this is something that's viable without breaking much in terms of backward compatibility i.e. user should still call sake, though possibly some of the commands are different, though preferably not
  • Target CMS 6
  • Replace as much of sake with symfony/console as possible

CMS 5 PRs

CMS 6 PRs

kitchen sink run
CI failures are pre-existing

@GuySartorelli
Copy link
Member

GuySartorelli commented Aug 31, 2024

I've gotten pretty far with this for everything included in installer. I'm nearly at the point where I can clean up and start writing tests (and then move onto the rest of kitchen sink).

One thing I'd like some opinions on is how the dev/ commands should be arranged.

Right now the PRs have these just swapping dev/ to dev:, i.e. you can run the commands like so:

HTTP route CLI command CLI alias (for backwards compat)
dev/tasks/my-task dev:tasks:my-task dev/tasks/my-task
dev/config dev:config dev/config
dev/build dev:build dev/build

Example of the existing command setup

This however keeps all of the commands clumped together in an unhelpful way, and means you have to type dev: before every command, which is completely unnecessary in the CLI. The only reason they had that historically is because sake was just a CLI wrapper for the HTTP controllers, so the routes had to be identical. Now they don't.

I would like to change the commands to be more meaningful in CLI, while keeping their HTTP routes as they currently are. That would look more like this:

HTTP route CLI command CLI alias (for backwards compat)
dev/tasks/my-task tasks:my-task dev/tasks/my-task
dev/config config:dump dev/config
dev/build db:build dev/build

Example of the proposed command setup

This gives us a more sensible grouping for the CLI commands, allows for new commands to be more easily added to those groupings in a meaningful way, reduces unnecessary key-strokes, and I think just looks way tidier.

(I'm planning on hiding the tasks from this initial list (at least if there are more than some configurable number of them) and only showing them when you run sake tasks (or sake dev:tasks if this proposal isn't accepted) so don't get too caught up on how those are filling the output)

@silverstripe/core-team Does anyone have any thoughts on this?

@wilr
Copy link
Member

wilr commented Sep 1, 2024

@GuySartorelli 100% agree. Coming from a laravel view that makes a lot more sense than prefixing everything dev. 👍

@emteknetnz
Copy link
Member Author

Looks good, happy to get rid of the dev prefix

@kinglozzer
Copy link
Member

+1 for getting rid of the dev prefix

@michalkleiner
Copy link
Contributor

All good to drop the dev: prefix.

@emteknetnz emteknetnz removed their assignment Sep 23, 2024
@GuySartorelli
Copy link
Member

GuySartorelli commented Sep 23, 2024

Running sake tasks lists a bunch of tasks in a mixture of casing, e.g. tasks:WorkflowReminderTask and tasks:content-review-emails. We should only have a single style, which to me seems like it could be the WorkflowReminderTask style as that matches the class name which people are familiar with

I think we should aim for lowercase task names for newly named tasks, because that's easier to type and is more consistent with basically everything else you'll ever do in CLI (at least for *nix).
Note that these names are also used for the URL segment, where lowercase with hyphens is also more standard than using capital letters.

I would prefer not to rename existing tasks that already have short names so that we can preserve backwards compatibility for them (I gave an explicit name to some tasks that were falling back to FQCN because the FQCN is really long and looks awful in the new sake tasks output).

Only exceptions would be for the two tasks in fluent which already has $segments in CMS 5 which didn't match the ClassName, they should say as is

Based on this comment it seems you agree that we should avoid renaming the tasks which already have short names defined. So this is only about tasks we're giving a command name where the legacy segment wasn't already defined

@GuySartorelli
Copy link
Member

GuySartorelli commented Sep 23, 2024

sake dev/tasks and dev/graphql and simply sake dev don't work like they used to, though dev/build and dev/config do work which is inconsistent

They can't work like they used to, because sake doesn't use the routed controllers to get or list info anymore. Lists of commands are handled by symfony/console internals.

sake tasks is a slightly special case because I've implemented logic to hide tasks from the main list if you have too many, so I made an explicit command for listing them - but that still just fires off the equivalent of sake list tasks. It doesn't use the old logic to list the tasks, nor should it.

Given the intention behind adding backwards compatibility is to allow scripts to continue working, I don't see any value in adding backwards compatibility for the commands that only listed what commands are available, given that doing so would be adding tech debt (immediately deprecated code).

@GuySartorelli
Copy link
Member

There's some text which doesn't make sense in a CLI context

I'll resolve the one you've listed, but the way you said that implies there are more cases? Please point them all out, since you saw them and I didn't it would be hard for me to fix them without them being pointed out.

@GuySartorelli
Copy link
Member

GuySartorelli commented Sep 23, 2024

I'm also finding the new permissions_for_browser_execution private static confusing for a few reasons:

  • It (probably correctly) uses an any check vs the LeftAndMain subclasses required_permission_codes's all

It's essentially doing the job of the now-deprecated init_permissions configuration property on the old controllers, e.g

private static $init_permissions = [
'ADMIN',
'ALL_DEV_ADMIN',
'CAN_DEV_CONFIG',
];

  • In 02_Hybrid_commands.php (rename to 02_Poly_commands.php) it says "An array of permissions a user must have to run the command in an HTTP request" which implies it's an 'all', however the fact that ADMIN is in all of these arrays implies they're all ADMIN only, which isn't the case.

Please point out things like this in the relevant PR - it's a lot easier for me to keep track of changes I need to make to a specific PR if the comment is in that PR.
I'll try to update the wording in a way that doesn't imply "all".

  • Also the anyone_with_dev_admin_permissions and anyone_with_task_permissions keys really confused me, I thought they were actually some sort of new functionality for a while until I realised they're just labels to try and be helpful. They're actually unhelpful so the keys should just be be removed

Those permissions already existed. I'm keeping the same permissions in order to preserve backwards compatibility.
Although if I've misunderstood what you're meaning it may pay to comment in context of the PR so I can see what you're talking about.

@emteknetnz
Copy link
Member Author

Running sake tasks lists a bunch of tasks in a mixture of casing ... Note that these names are also used for the URL segment

Yeah I'll assume that most most tasks are being run via the browser rather than CLI, simply because it's generally easier to login as an admin rather than SSH on to a production server, so the lower-case-with-dashes which $segment currently uses is probably the better standard.

There's some text which doesn't make sense in a CLI context ... Please point them all out

I had look through all the tasks, I could find any others like this one I already pointed out

sake dev/tasks and dev/graphql ... They can't work like they used to

All good

@GuySartorelli
Copy link
Member

All PRs merged. CI will be cleaned up in silverstripe/.github#313

@madmatt
Copy link
Member

madmatt commented Sep 27, 2024

Thank you to everyone who has worked on this, very glad to see this happening <3

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

No branches or pull requests

7 participants