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

Add git packages as VCS repositories #79

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

mortenscheel
Copy link
Contributor

I've changed the way packager:git works.
In stead of cloning the repository directly to the /packages/myVendor/myPackage folder, it is added as a VCS repository in composer.json and installed like any other package to the /vendor folder. After installing, it is symlinked to the /packages folder.

If the package origin is only specified as vendor/package in stead of a complete URL, it is assumed that the repository is located at https://github.com/vendor/package.

The packager:list command now has an extra column showing the Git status of the package. If packages are version controlled, it will whether they're Up to date, Ahead {number of commits} or Behind {number of commits}. If not, they're displayed as Not initialized.

I've add a couple of tests to ensure the new features are working correctly. They both clone your Jeroen-G/testassist repository, but it doesn't really matter which repository they use, if you want to change it to something else.

Let me know if anything needs to be changed.

/Morten

@mortenscheel
Copy link
Contributor Author

Sorry about that. I'll take a look at the failing test case. I'll probably have it fixed later this weekend.

Allow package-skeleton to be cached.
Only test download of skeleton once.
@mortenscheel
Copy link
Contributor Author

Okay, looks like the tests are green again.
Note that I've added "cache_skeleton" => false to the config file, which allows for faster installs (and tests).

Regarding style rules, I've tried a few different settings and plugins for PhpStorm, but nothing seems to match the StyleCI laravel preset. Do you have any tips you want to share?

@Jeroen-G
Copy link
Owner

Perhaps you can also use the skeleton for the tests, or perhaps a proper composer.json is required?

Regarding styleci, I use their standard Laravel preset as far as I know: https://styleci.readme.io/docs/presets

Reuse package created by first test.
Ensure composer commands are run without Xdebug enabled.
@mortenscheel
Copy link
Contributor Author

Yeah, I've just changed the packager:git test use packager-skeleton. I couldn't make it work earlier, but now it does.

So... quite a lot of changes. I've tried my best to make the tests run faster, but I can't speed up the composer require/remove calls. I've probably even made them a bit slower, by adding optimize-autoloader => true to Testbench's composer.json. Without that change, I couldn't be 100% sure that the installed ServiceProvider was registered correctly in the autoload files.

I did manage to save some time, by not repeating the entire packager:new installation multiple times. After the first test, the resulting package (and the autoload-files created by Composer) are stored and reused later, to quickly install a "fake" package.

The "cached skeleton" feature is not used in the tests any longer, since the other way is much faster. So you're welcome to remove the feature if you like, but I figure maybe some users would want that option.

I've also refactored a lot of code, so most of my changes have ended up in traits. The intention was to make it less messy, but I'm open to your input if you want it structured differently.

Besides that, the biggest change is probably in the way I test whether packages packages are installed/removed correctly. I trust the tests a lot more now. And I've added a few extra assertions where I thought they made sense.

Anyhoo, let me know what you think.

@Jeroen-G
Copy link
Owner

At this point, the speed of the tests don't really bother me. The fact that you trust the tests more now is much more appealing to me!


/**
* Determines the path to Composer executable
* @todo Might not work on Windows
Copy link
Owner

Choose a reason for hiding this comment

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

I have a Windows machine, so I will test this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Cool. I've removed the @todo

}

/**
* @depends test_new_package_is_created
Copy link
Owner

Choose a reason for hiding this comment

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

I didn't know about @depends, looks very clever.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't normally like writing tests that rely on other tests, but sometimes it's super convenient.

@@ -7,6 +7,7 @@
* Default: http://github.com/Jeroen-G/packager-skeleton/archive/master.zip
*/
'skeleton' => 'http://github.com/Jeroen-G/packager-skeleton/archive/master.zip',
'cache_skeleton' => false,
Copy link
Owner

Choose a reason for hiding this comment

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

What would be a proper place to document this? I'm thinking a line in just the config file might be enough?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Now I wonder if it's even worth keeping. The only benefit is that you save about a second of download time (if even that). On the other hands, it adds a layer of complexity, and people might end up using an outdated skeleton without knowing it.

* @todo Might not work on Windows
* @return string
*/
protected static function getComposerExecutable(): string
Copy link
Owner

@Jeroen-G Jeroen-G Jun 23, 2019

Choose a reason for hiding this comment

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

Why did you choose to make this (and the ones below) static?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm. Mostly just for convenience and old habits.
The whole initial setup of the Testbench environment runs in a static context (setupBeforeClass), before Laravel has even been initialized. This is necessary because I can't switch the app's base_path once it's already up and running.
But honestly I should change it back to non-static, since I can just call the methods from the $instance variable. I just didn't notice earlier :)


namespace JeroenG\Packager;

trait ProcessRunner
Copy link
Owner

Choose a reason for hiding this comment

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

Nice refactor 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Glad you like it. I considered calling the other one ComposerCommander or something like that, but decided to keep it boring...

@mortenscheel
Copy link
Contributor Author

mortenscheel commented Jun 23, 2019

WTF. One of the tests fail now, but only in PHP 7.2.
I'll have to install 7.2 and figure out why. I may not have time to fix it tonight though.

Edit: Super weird. All tests are green when i run them on 7.2. But Travis is unhappy.

@Jeroen-G
Copy link
Owner

Have you tried installing a package with tests? So far I can't get those tests to work :/

Default timeout is 60 seconds, which is usually enough. Sometimes running composer require takes longer, especially when resolving a package version, which exists in multiple repositories
@mortenscheel
Copy link
Contributor Author

mortenscheel commented Jul 6, 2019

The failing unit test was caused by a simple timeout, which is fixed now.

Have you tried installing a package with tests? So far I can't get those tests to work :/

Nope, I hadn't tried that until now, and I've been pulling my hair for a couple of hours without finding a good solution.
The root issue is that when you ´composer require´ a package, the package's dev-dependencies are ignored. Those are only installed if you run composer install in the package's root folder.

I tried using a composer merge-plugin which merges multiple composer.json files, but that only works if all the installed packages are compatible and don't have conflicting dependencies.

The way I see it, there's only one way to run package tests right now:

  1. cd projects/vendor/name
  2. composer install
  3. ./vendor/bin/phpunit

I tried writing a new Command to automate that workflow, but for some reason it won't work.

I'm afraid I'm all out of ideas here.

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.

None yet

2 participants