studio icon indicating copy to clipboard operation
studio copied to clipboard

Using studio along with a git branch workflow

Open RemiCollin opened this issue 8 years ago • 13 comments

I guess this issue is more related to the inner workings of composer than a studio issue, but I think it's quite relevant here.

We're using a git branching workflow on a project's package loaded with studio. Problem is, when switching the package to another branch than the 'dev-master' which is required in the main composer.json of the project, composer will drop the studio package in favor of the dev-master branch from the .git remote repository.

In order to use the studio package again, we then have to update the main project composer.json to require the 'dev-feature/branch' instead of the dev-master.

Is there a workaround around that ? If I remember correctly in previous studio version, it was working whatever branch you were using, which was a great workflow IMO.

RemiCollin avatar Apr 05 '16 08:04 RemiCollin

Hi,

I think one solution to this is to add an explicit "version": "dev-master" to your packages composer.json file. That way composer should identify it as the dev-master version and use the workbench package. Although I do not prefer this solution so much as using an explicit "version" in a packages' composer,json is IMHO not recommended.

buznablaster avatar Apr 05 '16 09:04 buznablaster

Hi folks, thanks for bringing this up!

I consider this a bug, too - it's clearly unexpected behavior. Without having given it much thought, our only way to fix this might be to build our own "repository" implementation that we use - it would probably build on top of Composer's path repository implementation, but would always return the current package - whether its branch matches the constraints in composer.json or not. Thoughts?

franzliedke avatar Apr 05 '16 10:04 franzliedke

Well, that would definitely do it for me :+1:

RemiCollin avatar Apr 05 '16 10:04 RemiCollin

hmm, having a quick look at ArrayRepository which is extended by PathRepository, https://github.com/composer/composer/blob/master/src/Composer/Repository/ArrayRepository.php perhaps it would be enough to override public function findPackage($name, $constraint)

what do you think ?

buznablaster avatar Apr 05 '16 10:04 buznablaster

@buznablaster Thanks for looking into this.

I played around a bit and it turns out it's a bit more complicated. When running composer update, Composer loads all packages via the repository's getPackages() method. If the packages returned by that method do not match the constraints checked against by the solver, then we have a problem. Digging further...

franzliedke avatar Apr 05 '16 12:04 franzliedke

Would it be possible to workaround this by hooking the symlink creation to SCRIPTEVENTS::POST_UPDATE_COMMAND , whichever version composer chose to install ?

(edit : i realize after posting this, that this may rise several issues, as not using the composer.json from tha managed package)..

I looked into composer code, and it doesn't look simple to bypass the constraint at all..

RemiCollin avatar Apr 05 '16 14:04 RemiCollin

Not completely sure, but I was afraid already we might have to do that

franzliedke avatar Apr 06 '16 00:04 franzliedke

Okay, as hinted previously, my plan here is to have Studio basically ignore the version constraint that you declare in composer.json.

In a perfect future, Studio will then probably display a warning that dependants that don't use Studio (as they shouldn't) will get a different version of the library using the current constraints. Given the big problems with the lockfile (#52), this might mean that we first run a normal composer update (i.e. properly downloading all files from Packagist etc.), before having Studio replace certain packages with symlinks (so that we keep a valid lock file).

Now for the hard part, the implementation...

franzliedke avatar Jul 29 '16 14:07 franzliedke

I just came across this issue myself. Knowing that I just need to temporarily change the branch in my main composer.json file is good enough as a short term fix.

Might be worth adding that as a note to the docs in the meanwhile?

Rjs37 avatar Oct 13 '16 19:10 Rjs37

@Rjs37 Can you post an example of what such a note could look like?

franzliedke avatar Oct 18 '16 21:10 franzliedke

I was thinking of something along the lines of the below, probably between the Loading local packages and Kickstarting sections.

Using branches on your package

When using local branches for your package, you will also need to update your composer.json. The branch declared in your composer.json must match the local branch of your package for composer update to work correctly:

"require": {
    "my/world-domination": "dev-feature/branch"
}

Rjs37 avatar Oct 19 '16 13:10 Rjs37

@Rjs37 Pulling my hair out for ages over that. Cheers!

@franzliedke Thanks for an awesome package. Love your work!

furey avatar Oct 24 '17 01:10 furey

I second the request to add a note to docs as suggested above https://github.com/franzliedke/studio/issues/56#issuecomment-254808455

weitzman avatar Jun 13 '18 19:06 weitzman