Skip to content

Conversation

@schlessera
Copy link
Member

@schlessera schlessera commented Mar 2, 2017

See #3850

Added scenarios:
- `Install a package that overrides a command bundled in source`
- `Install a package that overrides a bundled PHAR command`

Both scenarios are tagged with `@bootstrap`.

See #3850
Added scenarios:
- `Override command bundled with current source`
- `Override command bundled with PHAR`

Both scenarios are tagged with `@bootstrap`.

See #3850
Added scenarios:
- `Override command bundled with downloaded PHAR`
- `Install a package that overrides a command from a downloaded PHAR`

Both scenarios are tagged with `@bootstrap`.

See #3850
…endencies.

Added scenarios:
- `Basic Composer stack`
- `Composer stack with override requirement after WP-CLI`
- `Composer stack with override requirement before WP-CLI` (fails with current commit, as this is the issue to solve)

All three scenarios are tagged with `@bootstrap`.

See #3850
Added scenarios:
- `Override command bundled with Composer stack`
- `Install a package that overrides a command from a Composer stack`

Both scenarios are tagged with `@bootstrap`.

See #3850
The order of execution of the bootstrapping process has been heavily refactored
to contain everything in separate, isolated steps as far as currently possible.

There's a major issue remaining, that will need further discussion: the
autoloader for the framework itself (needed for any commands to register without
errors) and the autoloader for the bundled commands (that are required through
Composer) would need to be split and moved independently, but reside within the
same Composer autoloader setup.

See #3850
…k" autoloader and a "commands" autoloader.

Requires the package `wp-cli/autoload-splitter` that is yet to be created as a repository.

There's still an issue with the YAML loading, because it is not class-based.

See #3850

}

WP_CLI::add_command( 'cli', 'CLI_Command' );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it necessary to move this code? If not, can you revert the changeset so that it's possible to easily follow the file history?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was looking for a command that would not be split out, to use for the tests. So, the tests do test all of the different ways to override this command.

For this to work, however, the command itself needs to be autoloaded on-demand, not immediately loaded upon bootstrap.

This change allows the `Spyc` through an autoloader, as soon as the related pull request to the `mustangostang/spyc` package has been merged: mustangostang/spyc#66
These tests cannot work as long as there is no released PHAR version to download that includes the bootstrap changes from this branch.
@danielbachhuber
Copy link
Member

@schlessera Can you merge master?

- `"wp-cli/autoload-splitter": "dev-master"`
- `"mustangostang/spyc": "dev-master#1cea7c15324025cd7b62c8d47c10e1e94f634c1e"`
composer.json Outdated
"psr-0": { "WP_CLI": "php" }
"psr-0": { "WP_CLI": "php" },
"psr-4": { "": "php/commands/src" },
"classmap": [ "php/export" ]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This classmap shouldn't be necessary anymore...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm currently trying to figure out the autoloading in general here. There's still an issue with the Spyc class, my proposed change did not really help at all.

"""
And STDERR should be empty

@bootstrap
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if we were to create a feature/bootstrap.feature file? I think breaking things apart is typically easier than using a bunch of tag annotations.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I agree that is preferable. Now that most of the package have been taken out, it can more easily be contained.

The normal fork we were pulling in via a branch needs to be set in the `"repositories"` section and is only applied on the root package for security reasons.

To avoid WP-CLI breaking for people that pull it in via Composer, we replace the fork with a properly released package under a different name.

See #4017
schlessera added a commit to wp-cli/scaffold-package-command that referenced this pull request May 2, 2017
With the new hooks introduced in wp-cli/wp-cli@7fcee0e , we can now only load the commands if the parent they depend on has already been added.

This is needed because of the added flexibility provided by the bootstrap refactoring.

See wp-cli/wp-cli#3872
@schlessera
Copy link
Member Author

schlessera commented May 2, 2017

@danielbachhuber This should now be ready to be merged.

As we had already discussed, there's still two tests that are marked as @broken (and hence skipped on Travis):

  1. Composer stack with override requirement after WP-CLI
    The expected behavior is that the original WP-CLI command should run, not the override. The test shows that the override is run instead, though.
    I'm not yet sure whether the expected behavior is even feasible, but it should not pose any problem to existing code, as such a scenario was not at all supported before.

  2. Composer stack with override requirement before WP-CLI
    This is teh same test as 1., but in the opposite order, where we would expect the override to be active instead of the original command.
    The test shows that this is the case, but then the clean-up mysteriously fails and blocks Behat. I suspect this is due to the way the branch is pulled in. This will need further examination, but does not directly have anything to do with the behavior that is being tested.

@danielbachhuber danielbachhuber changed the title Refactor Bootstrap Process (WIP) Refactor Bootstrap Process May 2, 2017
@danielbachhuber danielbachhuber added this to the 1.2.0 milestone May 2, 2017
@danielbachhuber danielbachhuber merged commit d9d405a into master May 2, 2017
@danielbachhuber danielbachhuber deleted the 3850-refactor-loading-order branch May 2, 2017 16:05
Copy link

@masumkhan5479 masumkhan5479 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ftg

schlessera added a commit to wp-cli/scaffold-package-command that referenced this pull request Aug 9, 2022
With the new hooks introduced in wp-cli/wp-cli@7fcee0e , we can now only load the commands if the parent they depend on has already been added.

This is needed because of the added flexibility provided by the bootstrap refactoring.

See wp-cli/wp-cli#3872
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants