-
-
Notifications
You must be signed in to change notification settings - Fork 74
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
#52 Fixing the lock file #73
base: master
Are you sure you want to change the base?
Conversation
I have another commit that creates an The same directory is also used to store a copy of studio.json file to detect packages that are removed, so that we can restore the original into the vendor directory. |
Thanks for the initiative, I hope to review it early next week. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It still needs some more work and I forgot a few checks, I have time this weekend to fix a few things and make the code a bit nicer. Maybe I can add a few tests also would be really nice.
src/Composer/StudioPlugin.php
Outdated
|
||
} | ||
|
||
copy( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugly, also missing some checks if the studio.json file exists
src/Composer/StudioPlugin.php
Outdated
private function getPreviouslyManagedPaths() | ||
{ | ||
$targetDir = realpath($this->composer->getPackage()->getTargetDir()) . DIRECTORY_SEPARATOR . '.studio'; | ||
$config = Config::make("{$targetDir}/studio.json"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use directory seperator
src/Composer/StudioPlugin.php
Outdated
{ | ||
$repoManager = $this->composer->getRepositoryManager(); | ||
$composerConfig = $this->composer->getConfig(); | ||
$targetDir = realpath($this->composer->getPackage()->getTargetDir()) . '/.studio'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DIRECTORY_SEPARATOR
src/Composer/StudioPlugin.php
Outdated
|
||
// Creates the symlink to the package | ||
$filesystem = new Filesystem(); | ||
if (!$filesystem->isSymlinkedDirectory($destination)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this works on windows needs some testing
@SanderSander Wonderful stuff! Watching this to see how it all pans out! Thanks for looking into this issue, much appreciated! |
- Fix custom installer paths
I made everything better testable (first time with phpspec so suggestion are welcome). There are a few points of attention left.
|
@franzliedke Any change to give some feedback about the current approach? |
Sorry for the delay. And thanks for your hard work! This looks promising, I shall have a look soon. It's still on my list. :) |
@SanderSander Great job! Currently testing, it seems that it does not work anymore with path wildcards. Wrote a small fix here, however it changes the way Studio Config reads the path by extending wildcards to existing folders containing "composer.json". |
Nice! I have some time this weekend to work in this.
Then I think this PR is complete. Some other points (outside this PR)
|
Any hope that this fix gets merged? |
I am about to leave for vacation, but I promise that I will have a look when I return (in two weeks). |
So, still nothing @franzliedke ? Is there any known issue with this PR that's blocking the merge? |
@franzliedke +1 from me as well. It's already been 2 weeks :) |
Hi folks, sorry for the long absence. I've just released with a new version that takes care of other small issues / pull requests. Now for the elephant in the room... I just pulled this PR down into a local branch and will play around with it. Thanks for the awesome work, @SanderSander! I will try to turn this into a beta release quickly and all of you will have to try it out. 😉 |
👍 for merging this! |
@franzliedke any news about this? thanks for your work, helps a lot in our work! |
I created a repo with the last version of studio and the solution by @SanderSander |
@franzliedke @apfelbox We would love to use this project, but the manipulation of the |
Hey @scottsb, after reading #52, I think what I will try to have a look at this PR. 👍 |
@apfelbox Maybe I'm not following, but it seems like modifying the |
Yeah, but that would be intended. Because if you have a reference locally, that is not in the upstream repository, and you try to install this somewhere else, it should properly fail with "hey, I can't find this reference. Something is broken". That is actually really important, because "just ignore the missing reference" is a hard break: your project depends on code from your The right thing to do is to fail as early as possible – and that is in Just think of it this way: your code apparently requires the code from this reference, so installing it with any other version would invalidate the complete package management from composer. |
If the goal is to represent in the host project the version of the package as it exists locally in development, then there's another issue even if it can find the reference: you now have a lock file that may be inconsistent with the version constraint in composer.json, in a non-obvious way. (Composer won't warn about the lock being out of date because that's based on a hash of the Also, even updating the reference in the lock file is not a guarantee that the host package will have the right version of the code, because the reference is only the version that was installed when studio set up the symlink. It won't be automatically updated for further commits in the package (much less uncommitted work). My thought is that studio ought to serve as a way to "disconnect" a package from Composer so that you can work on a package within a host environment. So long as it's disconnected, the host project's Composer locks should not be updated. Then, when you are ready to release an update to the package, you can tag it and release it. Then you would tell Composer to do a typical |
This fixes the composer.lock file issue #52
The only problem is when the remote repository is updated or when you switch from version, composer prompts that it can't find the .git directory of the package.Creating a copy of the original downloaded package isn't really an option in my opinion because then it should be stored in the /vendor directory.The initial lookup for newer versions is cached by composer and works as it should.
Also it prevents users to have the
dev-master
tag in the composer.json.The symlinked directory can be checked out on any branch you would like too and is completely detached from composer.