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

Fixing the lock file #52

Open
janhartigan opened this issue Mar 23, 2016 · 54 comments
Open

Fixing the lock file #52

janhartigan opened this issue Mar 23, 2016 · 54 comments

Comments

@janhartigan
Copy link

Hey @franzliedke thanks a lot for taking the time to put together the recent release.

However, I have noticed one significant issue with the newly-generated composer.lock file. Normally composer generates something like this:

{
    "name": "owner/repo",
    "version": "dev-master",
    "source": {
        "type": "git",
        "url": "[email protected]:owner/repo.git",
        "reference": "2cf2e58fc8b71f44dbcca306cf7e16a65a2d4e97"
    },
    ...
}

There would also be a dist with the zipped contents of the git repo.

With the new updates, the composer lock file now looks like this:

{
    "name": "owner/repo",
    "version": "dev-master",
    "dist": {
        "type": "path",
        "url": "../../path/to/repo/",
        "reference": "2cf2e58fc8b71f44dbcca306cf7e16a65a2d4e97",
        "shasum": null
    },
    ...
}

Trouble with this is that when we push the code up through the pipeline, our servers will try to install that composer.lock file and it won't be able to figure out how to grab the dist. Since you're already using this in a real project, I'm guessing there's some other approach that I'm missing. Let me know what you think.

@franzliedke
Copy link
Owner

Darn, that really is a problem I did not foresee. I probably did not notice this because I did not commit the lock file (yet) in the projects where I was using this.

I'll have to think about that one for a bit...

@tobyzerner
Copy link

I'm having a hard time thinking of a clean way to fix this. Should the onus be on the user to temporarily disable studio and then run composer update if they want to commit an updated lock file? Maybe Studio could automate this process (studio lock or something)

@RemiCollin
Copy link
Contributor

I guess ideally Studio would hook in right after composer.lock file is created, right before generating autoload files. I don't have enough knowledge of the inner workings of composer to say if that's possible or not, though.

@franzliedke
Copy link
Owner

I haven't looked into the implementation yet, but if the entries in composer.lock are generated by the repository instances that Composer uses, we might be able to fix this by using our own repository implementation, as hinted at in #56.

@janhartigan
Copy link
Author

@franzliedke that sounds like a great idea. So everyone is aware, these are the repositories in question:

https://github.com/composer/composer/tree/master/src/Composer/Repository

Looks like the default version is the ComposerRepository. The one that Studio is currently using is the PathRepository.

Man, looking at that ComposerRepository, that library desperately needs some refactoring work.

Edit: Actually I guess we have to be careful here as we should fall back to the repository that would it have used if Studio didn't exist. That might be something like a VCS repository (as is the case in our system).

@jonnywilliamson
Copy link

I'm having this exact same issue. I can't commit my lock file at the moment.

I have no suggestions as I don't have enough programming skill to come up with a solution, but thanks for looking into this.

@mnpenner
Copy link

mnpenner commented May 24, 2016

So...until this is fixed, we have to manually edit studio.json, clear out the paths, run composer update on each of the repos, commit/push and then restore the paths?

studio scrap sounds like it wants to delete my whole project, I just wanted to temporarily unlink it.

@LavaToaster
Copy link

@mnpenner Out of curiosity, if you ran composer update --no-plugins does that work?

@janhartigan
Copy link
Author

janhartigan commented May 24, 2016

@mnpenner alternatively you can downgrade to an older version of studio (0.9.5). That's what we've done until it's fixed.

@warksit
Copy link

warksit commented Jul 5, 2016

@Lavoaster yes totally, Have changed install scripts on production servers to composer update --no-plugins (and other flags such as --no-dev) and all good.

@janhartigan
Copy link
Author

@warksit trouble with that is that composer update wasn't really intended to be run in a production environment.

@swt83
Copy link

swt83 commented Jul 27, 2016

I can't use version 0.9.5 bc Composer gives me some error:

  Problem 1
    - Installation request for franzl/studio 0.9.5 -> satisfiable by franzl/studio[0.9.5].
    - franzl/studio 0.9.5 requires composer-plugin-api 1.0.0 -> no matching package found.

The newer versions of this repo (anything post 0.9.5) don't seem to actually load the packages referenced in my studio.json file. So now I'm stuck.

@janhartigan
Copy link
Author

@swt83 unfortunately to continue using 0.9.5, you need to have version 1.0.0 of composer installed. There isn't really a good way around this at the moment.

@swt83
Copy link

swt83 commented Jul 28, 2016

Why am I not able to get studio to work with version 0.11.0? The studio.json file is correct, but the code isn't actually loading into my app.

@janhartigan
Copy link
Author

@swt83 so you're running the latest composer version and you've successfully run composer global require franzl/studio?

@swt83
Copy link

swt83 commented Jul 28, 2016

I'm not using the global method. I have the studio package installed on the project and I have the studio.json file setup, and when I run composer update it lists off all the studio packages it is loading -- but then the packages don't actually become available to my project.

@warksit
Copy link

warksit commented Jul 28, 2016

@janhartigan you're right. However --no-plugins works fine with composer install.

@franzliedke
Copy link
Owner

I'll get back to you later today, sorry for the radio silence lately, folks.

@swt83
Copy link

swt83 commented Jul 28, 2016

I think you guys know all this stuff already, but here is my report:

I ended up removing Studio from my project and manually setting up a path type repository in my composer.json file. I used a wildcard * to have it load my entire packages directory, which is where I am working with all my private repos.

"repositories": [
        {
            "type": "path",
            "url": "workbench/*/*"
        }
],

I had to also manually add all my packages VCS dependencies to the master composer.json for my project because Composer won't recursively load VCS dependencies.

This was all a massive pain but it's got me up and running again.

For whatever reason Studio says it's loading packages when I run composer update but those packages just don't work. The old 0.9.5 version had kept me going for a few months, but now that won't work anymore due to Composer updates. So now I'm left with manually setting up the composer.json file as described above.

@janhartigan
Copy link
Author

@warksit hm strange. As I understand it, composer install merely tries to build a project from a composer.lock file. If a lock file has this:

{
    "name": "owner/repo",
    "version": "dev-master",
    "dist": {
        "type": "path",
        "url": "../../path/to/repo/",
        "reference": "2cf2e58fc8b71f44dbcca306cf7e16a65a2d4e97",
        "shasum": null
    },
    ...
}

How could it know where to get the repo, if not using the path method on the local file system? I haven't tested this locally as I'm still using 0.9.5, but you may want to double check that.

@swt83 hm must be a quirk of the non-global version. In the global version you just need to install it and have a studio.json file next to your composer.json file. I'm guessing that @franzliedke has some ideas up his sleeve.

Also...hi @franzliedke! No worries about the radio silence, if I really wanted to get anything done, I should just fix it myself and create a PR.

@franzliedke
Copy link
Owner

franzliedke commented Jul 29, 2016

@swt83 The structure of studio.json changed in v0.11.0. So that probably explains why things did not work anymore after the upgrade. Although technically I built things in such a way that it should fall back to the old parser, so that is confusing.

Can you post your studio.json, please?

Also, if you run studio create ... it should rewrite the file to the new structure. (You can then use studio scrap to get rid of the temporarily created package.)

P.S.: Please open a new issue about this, it seems to be unrelated.

@rask
Copy link
Contributor

rask commented Oct 26, 2016

Any news on this? Currently tiptoeing around the composer.lock related issue while sharing projects to teammates. Not a huge issue right now, but would like to see this streamlined a bit. :)

@laurencei
Copy link

laurencei commented Jan 30, 2017

Hi everyone,

So I started using this package, but ran into this issue with composer.lock.

I ended up removing the studio package - but using the core concept in a different way. Rather than trying to modify .lock files and change the inner workings of composer - I think it is easier to let composer do its own thing - and just hook in before and after.

The concept is change the script to do;

  1. Remove the symlink file
  2. Run composer update (let it run normally)
  3. Remove the package folder
  4. Re-symlink

This means composer has no idea and is completely unaffected by any local development. The only thing that will occur during step 2 is composer will detect your package is not actually in the vendor file, and re-download the current "latest" from packagist - but that is unlikely to be a big issue (especially as it'll probably be cached anyway).

I've started using this for me - and it is working perfectly. The composer.lock is completely unaffected and is totally unaware of what is going on.

Maybe this concept could be used in this package? You could register each package as you currently do with studio - then have it run hooks before and after to perform the commands as needed for each package rather than during the update/install;

Here are the commands I am using:

rm /full/path/to/your/project/vendor/your-vendor-name/your-package-name
composer update
rm /full/path/to/your/project/vendor/your-vendor-name/your-package-name -rf
ln -s /full/path/to/your/project/vendor/your-vendor-name/your-package-name /full/path/to/local/your-package-name

@franzliedke
Copy link
Owner

Hi @lioannou!

I agree this is the best way forward. So, basically, Studio would always load all required projects via symlink, if it can find them locally, doing so after Composer does its usual thing and resolves the packages from Packagist etc. (this would probably still need the local repository as fallback, for when the package hasn't yet been added to Packagist).

This leaves the question of what happens when a package is loaded via symlink - just because it is there -, despite not matching the version constraint defined in composer.json. Is it okay if we simply show a warning in that case?

@laurencei
Copy link

laurencei commented Jan 30, 2017

this would probably still need the local repository as fallback, for when the package hasn't yet been added to Packagist

It could be a private VCS etc though. And people who want to develop a new package can create a local version otherwise.

This leaves the question of what happens when a package is loaded via symlink - just because it is there -, despite not matching the version constraint defined in composer.json. Is it okay if we simply show a warning in that case?

Is it any different to what Studio already does though? You could do this:

> composer update
Studio: Hey - I'm removing symlinks for Package 1, Package 2 and Package 3
composer ... updating... beep... boop.... done...
Studio: Hey - now that Composer is finished - I've resymlinked Package 1, Package 2 and Package 3 to your local development version (this may be different from your composer.lock file)

That makes it visually explicit what packages have had there symlinks removed and/or re-add?

@janhartigan
Copy link
Author

This is actually the implementation that we've already done in our system. There are some issues with permissions (especially in Windows) if you use PHP's symlink. The scripts also handle the scenario where you try linking and it's already linked, and if you try unlinking when it's already unlinked. In the end we saw the fewest issues when just building the exec commands manually. You guys can use this if you find it useful.

Here's are the scripts:

<?php namespace App\Console\Commands;

use Illuminate\Console\Command;

class LinkDevelopmentCode extends Command {

	/**
	 * The console command name
	 *
	 * @var string
	 */
	protected $name = 'api:link-dev-code';

	/**
	 * The console command description
	 *
	 * @var string
	 */
	protected $description = 'Links the development code';

	/**
	 * Execute the console command
	 */
	public function fire()
	{
		$targetPath = base_path('vendor' . DIRECTORY_SEPARATOR . 'path' . DIRECTORY_SEPARATOR . 'to' . DIRECTORY_SEPARATOR . 'api');

		if (!$apiDevPath = env('API_DEVELOPMENT_PATH'))
			return;

		if (!is_dir($apiDevPath))
			return $this->error("Could not find the API development path at {$apiDevPath}.");

		//if this is a sym link, delete it
		if (file_exists($targetPath) && $this->pathIsLink($targetPath))
		{
			exec($this->buildDeleteLinkCommand($targetPath));
			$this->info("Existing symlink deleted");
		}
		//if this is a directory move it to its stored location
		else if (is_dir($targetPath))
		{
			exec($this->buildMoveDirectoryCommand($targetPath));
			$this->info("Original vendor path/to/api directory stowed in the closet");
		}

		exec($this->buildLinkCommand($apiDevPath, $targetPath));

		$this->info("The symlink was created!");
	}

	/**
	 * Determines if the provided path is a symbolic link
	 *
	 * @param  string    $path
	 *
	 * @return bool
	 */
	protected function pathIsLink($path)
	{
		return is_link($path) || (array_diff(stat($path), lstat($path)));
	}

	/**
	 * Builds the OS-dependent symbolic linking command
	 *
	 * @param  string    $apiDevPath
	 * @param  string    $targetPath
	 *
	 * @return string
	 */
	protected function buildLinkCommand($apiDevPath, $targetPath)
	{
		if ($this->isWindows())
			return "mklink /J {$targetPath} {$apiDevPath}";

		return "ln -s {$apiDevPath} {$targetPath}";
	}

	/**
	 * Builds the OS-dependent link deletion command
	 *
	 * @param  string    $targetPath
	 *
	 * @return string
	 */
	protected function buildDeleteLinkCommand($targetPath)
	{
		if ($this->isWindows())
			return "rd {$targetPath}";

		return "rm {$targetPath}";
	}

	/**
	 * Builds the OS-dependent directory move command
	 *
	 * @param  string    $targetPath
	 *
	 * @return string
	 */
	protected function buildMoveDirectoryCommand($targetPath)
	{
		$newTargetPath = $targetPath . 'installed';

		if ($this->isWindows())
			return "move \"{$targetPath}\" \"{$newTargetPath}\"";

		return "mv {$targetPath} {$newTargetPath}";
	}

	/**
	 * Determines if the current OS is Windows
	 *
	 * @return bool
	 */
	protected function isWindows()
	{
		return strpos(php_uname(), 'Windows') !== false;
	}

}

And here's the unlinking command:

<?php namespace App\Console\Commands;

use Illuminate\Console\Command;

class UnlinkDevelopmentCodeCommand extends Command {

	/**
	 * The console command name
	 *
	 * @var string
	 */
	protected $name = 'api:unlink-dev-code';

	/**
	 * The console command description
	 *
	 * @var string
	 */
	protected $description = 'Unlinks the development API code';

	/**
	 * Execute the console command
	 */
	public function fire()
	{
		$vendorPath = base_path('vendor' . DIRECTORY_SEPARATOR . 'path' . DIRECTORY_SEPARATOR . 'to' . DIRECTORY_SEPARATOR . 'api');

		//if this is a sym link, delete it
		if (file_exists($vendorPath) && $this->pathIsLink($vendorPath))
		{
			exec($this->buildDeleteLinkCommand($vendorPath));

			$this->info("Existing API symlink removed");
		}

		//if the stored vendor path already exists, move it into its original location
		if (file_exists($this->buildStoredVendorPath($vendorPath)))
		{
			exec($this->buildMoveDirectoryCommand($vendorPath));

			$this->info("Original Composer API installation restored");
		}
	}

	/**
	 * Determines if the provided path is a symbolic link
	 *
	 * @param  string    $path
	 *
	 * @return bool
	 */
	protected function pathIsLink($path)
	{
		return is_link($path) || (array_diff(stat($path), lstat($path)));
	}

	/**
	 * Builds the OS-dependent directory move command
	 *
	 * @param  string    $vendorPath
	 *
	 * @return string
	 */
	protected function buildMoveDirectoryCommand($vendorPath)
	{
		$storedVendorPath = $this->buildStoredVendorPath($vendorPath);

		if ($this->isWindows())
			return "move {$storedVendorPath} {$vendorPath}";

		return "mv {$storedVendorPath} {$vendorPath}";
	}

	/**
	 * Builds the OS-dependent link deletion command
	 *
	 * @param  string    $vendorPath
	 *
	 * @return string
	 */
	protected function buildDeleteLinkCommand($vendorPath)
	{
		if ($this->isWindows())
			return "rd {$vendorPath}";

		return "rm {$vendorPath}";
	}

	/**
	 * Builds the vendor path location where the composer api installation is stored
	 *
	 * @param  string    $vendorPath
	 *
	 * @return string
	 */
	protected function buildStoredVendorPath($vendorPath)
	{
		return $vendorPath . 'installed';
	}

	/**
	 * Determines if the current OS is Windows
	 *
	 * @return bool
	 */
	protected function isWindows()
	{
		return strpos(php_uname(), 'Windows') !== false;
	}

}

franzliedke added a commit that referenced this issue Dec 2, 2017
This is a fundamental rewrite of the Composer integration. Now, instead
of adding the loaded paths to Composer's search path (by creating path
repositories for them), we replace the packages downloaded by Composer
that can be found in the loaded paths by symlinks to the local paths.

Doing so requires us to hook into the autoload dumper, which now has to
respect the rules in the local path, not those obtained from Packagist.

All of this should hopefully fix several issues, most importantly:
- Composer's lock file will be written before Studio does its magic,
  therefore not causing any conflicts with other developers' setups.
- Different version constraints on symlinked packages won't cause
  problems anymore. Any required packages that are found in loaded paths
  will be loaded, no matter the branch or version they are on.

Open questions:
- How should packages be handled that have not yet been added to
  Packagist? (Proposed solution: Create path repositories for the loaded
  paths, but *append* them instead of *prepending*, so that they will
  only be used as fallback, if Packagist does not yield any results.)
- Should we validate the constraints from composer.json before creating
  symlinks? With this setup, everything might be working locally, but
  not when downloading the package from Packagist (as another version
  may be downloaded instead).

Refs #52, #58, #65, #72.
@franzliedke
Copy link
Owner

Whew, that took a while. Another vacation passed. Sorry, guys.

I worked on this, and I think I found a solution. Please try out the newly released 0.14.0-beta1 version. I am hoping this issue will be gone.

(Note that you will have to run composer update and composer dump-autoload for the installation of any package.)

I am very tired right now, so let me just quote the commit message here:

This is a fundamental rewrite of the Composer integration. Now, instead
of adding the loaded paths to Composer's search path (by creating path
repositories for them), we replace the packages downloaded by Composer
that can be found in the loaded paths by symlinks to the local paths.

Doing so requires us to hook into the autoload dumper, which now has to
respect the rules in the local path, not those obtained from Packagist.

All of this should hopefully fix several issues, most importantly:

  • Composer's lock file will be written before Studio does its magic,
    therefore not causing any conflicts with other developers' setups.
  • Different version constraints on symlinked packages won't cause
    problems anymore. Any required packages that are found in loaded paths
    will be loaded, no matter the branch or version they are on.

Open questions:

  • How should packages be handled that have not yet been added to
    Packagist? (Proposed solution: Create path repositories for the loaded
    paths, but append them instead of prepending, so that they will
    only be used as fallback, if Packagist does not yield any results.)
  • Should we validate the constraints from composer.json before creating
    symlinks? With this setup, everything might be working locally, but
    not when downloading the package from Packagist (as another version
    may be downloaded instead).

Looking forward to your reports and your input. 😄

@franzliedke
Copy link
Owner

Any luck anyone? A simple "Seems to work" is welcome, too.

And yes, the irony of me rushing all of you after taking so long myself is not lost on me. In case someone wondered. 😉

@nathanmerrill
Copy link

nathanmerrill commented Dec 4, 2017

I can't get it to work (but it may be my fault, I'm unsure). Here's what I've done:

I removed the composer.lock file and the symlinked folder from /vendor. I ran composer dump-autoload and then composer update, which gives me:

The requested package my/package could not be found in any version

@nathanmerrill
Copy link

I'd also like to note that when I run "composer update" on the beta version, I'm not getting the "Loading path ..." message I always do. When I switch back to the old studio version, it appears again.

@franzliedke
Copy link
Owner

@nathanmerrill Thanks for the feedback!

Some notes:

  • Right now, the beta version only works for packages that are also registered on Packagist. Any chance you are testing with a purely local package? I plan to bring that feature back, but haven't yet gotten around to do so.
  • Loading path...: I removed that message in the beta version, might bring it back. There should be other Studio output, though, if I am not mistaken.
  • Don't forget to run composer dump-autoload again at the very end.
  • Try removing the entire vendor dir before running composer update to be on the safe side.

@nathanmerrill
Copy link

My package is not registered on Packagist. The repo is included in the "repositories" section of my "composer.json", so it sounds like that that is what I'm waiting for.

Thanks

@ElfSundae
Copy link

@franzliedke It works like a charm 👍 big thanks ❤️

BTW, it seems Studio only works for packages required with dev version, like dev-master, *@dev, 1.x-dev ?
I don't know if it is possible to symlink a local path for a stable package, e.g. ~1.0

@ElfSundae
Copy link

One of my package can not be loaded...
And it seems because the local package was loaded twice.

Reading /private/tmp/ddd/vendor/composer/installed.json
Writing lock file
Generating autoload files
Executing command (/Volumes/HDD/projects/php-packages/urlsafe-base64/): git branch --no-color --no-abbrev -v
Executing command (/Volumes/HDD/projects/php-packages/urlsafe-base64/): git log -n1 --pretty=%H
[Studio] Loading package elfsundae/urlsafe-base64-9999999-dev
Executing command (/Volumes/HDD/projects/php-packages/urlsafe-base64/): git branch --no-color --no-abbrev -v
Executing command (/Volumes/HDD/projects/php-packages/urlsafe-base64/): git log -n1 --pretty=%H
[Studio] Loading package elfsundae/urlsafe-base64-9999999-dev

                                                                                  
  [InvalidArgumentException]                                                      
  Package elfsundae/urlsafe-base64-9999999-dev seems not been installed properly  
                                                                                  

Exception trace:
 () at phar:///usr/local/Cellar/composer/1.5.5/libexec/composer.phar/src/Composer/Downloader/DownloadManager.php:156
 Composer\Downloader\DownloadManager->getDownloaderForInstalledPackage() at phar:///usr/local/Cellar/composer/1.5.5/libexec/composer.phar/src/Composer/Downloader/DownloadManager.php:294
 Composer\Downloader\DownloadManager->remove() at phar:///usr/local/Cellar/composer/1.5.5/libexec/composer.phar/src/Composer/Installer/LibraryInstaller.php:213
 Composer\Installer\LibraryInstaller->removeCode() at phar:///usr/local/Cellar/composer/1.5.5/libexec/composer.phar/src/Composer/Installer/LibraryInstaller.php:126
 Composer\Installer\LibraryInstaller->uninstall() at /Volumes/HDD/projects/github/studio/src/Composer/StudioPlugin.php:72
 Studio\Composer\StudioPlugin->symlinkStudioPackages() at n/a:n/a
 call_user_func() at phar:///usr/local/Cellar/composer/1.5.5/libexec/composer.phar/src/Composer/EventDispatcher/EventDispatcher.php:171
 Composer\EventDispatcher\EventDispatcher->doDispatch() at phar:///usr/local/Cellar/composer/1.5.5/libexec/composer.phar/src/Composer/EventDispatcher/EventDispatcher.php:96
 Composer\EventDispatcher\EventDispatcher->dispatchScript() at phar:///usr/local/Cellar/composer/1.5.5/libexec/composer.phar/src/Composer/Installer.php:321
 Composer\Installer->run() at phar:///usr/local/Cellar/composer/1.5.5/libexec/composer.phar/src/Composer/Command/UpdateCommand.php:159
 Composer\Command\UpdateCommand->execute() at phar:///usr/local/Cellar/composer/1.5.5/libexec/composer.phar/vendor/symfony/console/Command/Command.php:266
 Symfony\Component\Console\Command\Command->run() at phar:///usr/local/Cellar/composer/1.5.5/libexec/composer.phar/vendor/symfony/console/Application.php:861
 Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/Cellar/composer/1.5.5/libexec/composer.phar/vendor/symfony/console/Application.php:208
 Symfony\Component\Console\Application->doRun() at phar:///usr/local/Cellar/composer/1.5.5/libexec/composer.phar/src/Composer/Console/Application.php:245
 Composer\Console\Application->doRun() at phar:///usr/local/Cellar/composer/1.5.5/libexec/composer.phar/vendor/symfony/console/Application.php:127
 Symfony\Component\Console\Application->run() at phar:///usr/local/Cellar/composer/1.5.5/libexec/composer.phar/src/Composer/Console/Application.php:100
 Composer\Console\Application->run() at phar:///usr/local/Cellar/composer/1.5.5/libexec/composer.phar/bin/composer:54
 require() at /usr/local/Cellar/composer/1.5.5/libexec/composer.phar:24

update [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--lock] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [--with-dependencies] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [-i|--interactive] [--root-reqs] [--] [<packages>]...

@PapsOu
Copy link

PapsOu commented Jan 31, 2018

@ElfSundae, @nathanmerrill : I've got the same issue with the beta version. But my package is not loaded twice :

$ composer update -v

Loading composer repositories with package information
Updating dependencies (including require-dev)
Dependency resolution completed in 4.124 seconds
Analyzed 16937 packages to resolve dependencies
Analyzed 1666364 rules to resolve dependencies
Nothing to install or update
Dependency resolution completed in 0.001 seconds
Generating autoload files
[Studio] Loading package sil-project/platform-9999999-dev
ocramius/package-versions:  Generating version class...
ocramius/package-versions: ...done generating version class
[Studio] Loading package sil-project/platform-9999999-dev

                                                                              
  [InvalidArgumentException]                                                  
  Package sil-project/platform-9999999-dev seems not been installed properly  
                                                                              

Exception trace:
 () at phar:///home/PapsOu/bin/composer/src/Composer/Downloader/DownloadManager.php:156
 Composer\Downloader\DownloadManager->getDownloaderForInstalledPackage() at phar:///home/PapsOu/bin/composer/src/Composer/Downloader/DownloadManager.php:294
 Composer\Downloader\DownloadManager->remove() at phar:///home/PapsOu/bin/composer/src/Composer/Installer/LibraryInstaller.php:213
 Composer\Installer\LibraryInstaller->removeCode() at phar:///home/PapsOu/bin/composer/src/Composer/Installer/LibraryInstaller.php:126
 Composer\Installer\LibraryInstaller->uninstall() at /home/PapsOu/.composer/vendor/franzl/studio/src/Composer/StudioPlugin.php:72
 Studio\Composer\StudioPlugin->symlinkStudioPackages() at n/a:n/a
 call_user_func() at phar:///home/PapsOu/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:171
 Composer\EventDispatcher\EventDispatcher->doDispatch() at phar:///home/PapsOu/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:96
 Composer\EventDispatcher\EventDispatcher->dispatchScript() at phar:///home/PapsOu/bin/composer/src/Composer/Installer.php:322
 Composer\Installer->run() at phar:///home/PapsOu/bin/composer/src/Composer/Command/UpdateCommand.php:161
 Composer\Command\UpdateCommand->execute() at phar:///home/PapsOu/bin/composer/vendor/symfony/console/Command/Command.php:242
 Symfony\Component\Console\Command\Command->run() at phar:///home/PapsOu/bin/composer/vendor/symfony/console/Application.php:842
 Symfony\Component\Console\Application->doRunCommand() at phar:///home/PapsOu/bin/composer/vendor/symfony/console/Application.php:193
 Symfony\Component\Console\Application->doRun() at phar:///home/PapsOu/bin/composer/src/Composer/Console/Application.php:251
 Composer\Console\Application->doRun() at phar:///home/PapsOu/bin/composer/vendor/symfony/console/Application.php:117
 Symfony\Component\Console\Application->run() at phar:///home/PapsOu/bin/composer/src/Composer/Console/Application.php:100
 Composer\Console\Application->run() at phar:///home/PapsOu/bin/composer/bin/composer:58
 require() at /home/PapsOu/bin/composer:24

@ElfSundae
Copy link

@PapsOu try:

rm -rf vendor
composer update --no-autoloader
composer dump-autoload

d4e19eb#commitcomment-26333596

@PapsOu
Copy link

PapsOu commented Jan 31, 2018

@ElfSundae : Hum, it works, but composer trigger symfony post script, that fails because autoload is not generated :-D

@ElfSundae
Copy link

What is your scripts config in the composer.json file?

@PapsOu
Copy link

PapsOu commented Jan 31, 2018

@ElfSundae : https://github.com/libre-informatique/LISemSymfonyProject/blob/wip-platform/composer.json

But that's normal, all symfony 2/3 projects have these post-scripts (that uses symfony commands)

@ElfSundae
Copy link

@PapsOu You can rename post-install-cmd to post-autoload-dump, and delete post-update-cmd

"scripts": {
  "post-autoload-dump": [
      "@symfony-scripts",
      "@git-hook"
  ]
}

@PapsOu
Copy link

PapsOu commented Jan 31, 2018

Hum, this solution doesn't seems to be a good one. I'll prefer wating a stable release of Studio (with the usage of composer update without the --no-autoloader option).

@teohhanhui
Copy link

teohhanhui commented Mar 15, 2018

How should packages be handled that have not yet been added to
Packagist? (Proposed solution: Create path repositories for the loaded
paths, but append them instead of prepending, so that they will
only be used as fallback, if Packagist does not yield any results.)

In no case should we touch composer.json or composer.lock, otherwise it defeats the purpose. For vcs packages, e.g. installed from a github.com repository (perhaps overriding a Packagist package, or it could just be an unpublished package), the symlink should be created after composer update, just like for Packagist packages.

@weitzman
Copy link

weitzman commented Apr 3, 2018

Unfortunately composer update failed for me.

~/reps/mass (develop=) $ studio load /Users/moshe.weitzman/drush

                                                                                                                        
 [OK] Packages matching the path /Users/moshe.weitzman/drush will now be loaded by Composer.                            
                                                                                                                        

~/reps/mass (develop=) $ composer update drush/drush -v
Gathering patches for root package.
Loading composer repositories with package information
Updating dependencies (including require-dev)                                              
	Dependency resolution completed in 2.889 seconds
Analyzed 18043 packages to resolve dependencies
Analyzed 550691 rules to resolve dependencies
Dependency resolution completed in 0.010 seconds
Package operations: 0 installs, 1 update, 0 removals
Updates: drush/drush:9.2.2
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
Found 8 patches for drupal/core.
Found 1 patches for drupal/workbench_moderation.
Found 1 patches for drupal/crazyegg.
Found 1 patches for drupal/password_policy.
Found 2 patches for drupal/tfa.
Found 1 patches for drupal/username_enumeration_prevention.
Found 2 patches for drupal/entity_browser.
Found 1 patches for drupal/access_unpublished.
Found 1 patches for drupal/field_group.
Found 1 patches for drupal/better_field_descriptions.
Found 1 patches for drupal/metatag.
Found 1 patches for drupal/media.
Found 1 patches for drupal/media_entity_document.
Found 1 patches for drupal/media_entity_download.
Found 2 patches for drupal/prlp.
Found 1 patches for drupal/pathauto.
Found 1 patches for drupal/subpathauto.
Found 4 patches for drupal/xmlsitemap.
Found 1 patches for drupal/conditional_fields.
Found 1 patches for blakestein/datalayer.
Found 1 patches for drupal/scheduler.
Found 1 patches for palantirnet/workbench_tabs.
  - Updating drush/drush (9.2.1 => 9.2.2): Downloading (100%) Extracting archive
No patches found for drush/drush.
Package egeloen/http-adapter is abandoned, you should avoid using it. Use php-http/httplug instead.
Package guzzle/cache is abandoned, you should avoid using it. Use guzzle/guzzle instead.
Package guzzle/common is abandoned, you should avoid using it. Use guzzle/guzzle instead.
Package guzzle/http is abandoned, you should avoid using it. Use guzzle/guzzle instead.
Package guzzle/inflection is abandoned, you should avoid using it. Use guzzle/guzzle instead.
Package guzzle/parser is abandoned, you should avoid using it. Use guzzle/guzzle instead.
Package guzzle/service is abandoned, you should avoid using it. Use guzzle/guzzle instead.
Package guzzle/stream is abandoned, you should avoid using it. Use guzzle/guzzle instead.
Writing lock file
Generating autoload files
[Studio] Loading package drush/drush-9999999-dev
Removing packages services cache file:
/Users/moshe.weitzman/reps/mass/vendor/drupal/console/extend.console.uninstall.services.yml
Creating packages services cache file: 
/Users/moshe.weitzman/reps/mass/vendor/drupal/console/extend.console.uninstall.services.yml
[Studio] Loading package drush/drush-9999999-dev

                                                                     
  [InvalidArgumentException]                                         
  Package drush/drush-9999999-dev seems not been installed properly  
                                                                     

Exception trace:
 () at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/Downloader/DownloadManager.php:156
 Composer\Downloader\DownloadManager->getDownloaderForInstalledPackage() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/Downloader/DownloadManager.php:294
 Composer\Downloader\DownloadManager->remove() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/Installer/LibraryInstaller.php:213
 Composer\Installer\LibraryInstaller->removeCode() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/Installer/LibraryInstaller.php:126
 Composer\Installer\LibraryInstaller->uninstall() at /Users/moshe.weitzman/.composer/vendor/franzl/studio/src/Composer/StudioPlugin.php:72
 Studio\Composer\StudioPlugin->symlinkStudioPackages() at n/a:n/a
 call_user_func() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/EventDispatcher/EventDispatcher.php:171
 Composer\EventDispatcher\EventDispatcher->doDispatch() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/EventDispatcher/EventDispatcher.php:96
 Composer\EventDispatcher\EventDispatcher->dispatchScript() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/Installer.php:322
 Composer\Installer->run() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/Command/UpdateCommand.php:161
 Composer\Command\UpdateCommand->execute() at phar:///Users/moshe.weitzman/bin/composer.phar/vendor/symfony/console/Command/Command.php:242
 Symfony\Component\Console\Command\Command->run() at phar:///Users/moshe.weitzman/bin/composer.phar/vendor/symfony/console/Application.php:842
 Symfony\Component\Console\Application->doRunCommand() at phar:///Users/moshe.weitzman/bin/composer.phar/vendor/symfony/console/Application.php:193
 Symfony\Component\Console\Application->doRun() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/Console/Application.php:251
 Composer\Console\Application->doRun() at phar:///Users/moshe.weitzman/bin/composer.phar/vendor/symfony/console/Application.php:117
 Symfony\Component\Console\Application->run() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/Console/Application.php:100
 Composer\Console\Application->run() at phar:///Users/moshe.weitzman/bin/composer.phar/bin/composer:58
 require() at /Users/moshe.weitzman/bin/composer.phar:24

update [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--lock] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [--with-dependencies] [--with-all-dependencies] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [-i|--interactive] [--root-reqs] [--] [<packages>]...

@weitzman
Copy link

tried the 0.14.0-beta1 again on another project and composer update initially failed with the log below. the long package name that composer is making includes the current branch name thats checked out. I tried going back to a more standard branch but same error. Happy to provide more info if anyone wants to debug this.

~/reps/apple/pds (master=) $ composer update -v apple-drupal/apple_saml
> pre-update-cmd: DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)                                        
Dependency resolution completed in 0.749 seconds
Analyzed 16478 packages to resolve dependencies
Analyzed 1224519 rules to resolve dependencies
Nothing to install or update
Dependency resolution completed in 0.001 seconds
Generating autoload files
[Studio] Loading package apple-drupal/apple_saml-dev-features/AA-89-logout
[Studio] Loading package apple-drupal/apple_saml-dev-features/AA-89-logout

                                                                                               
  [InvalidArgumentException]                                                                   
  Package apple-drupal/apple_saml-dev-features/AA-89-logout seems not been installed properly  
                                                                                               

Exception trace:
 () at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/Downloader/DownloadManager.php:156
 Composer\Downloader\DownloadManager->getDownloaderForInstalledPackage() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/Downloader/DownloadManager.php:294
 Composer\Downloader\DownloadManager->remove() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/Installer/LibraryInstaller.php:224
 Composer\Installer\LibraryInstaller->removeCode() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/Installer/LibraryInstaller.php:137
 Composer\Installer\LibraryInstaller->uninstall() at /Users/moshe.weitzman/reps/apple/pds/vendor/composer/installers/src/Composer/Installers/Installer.php:127
 Composer\Installers\Installer->uninstall() at /Users/moshe.weitzman/.composer/vendor/franzl/studio/src/Composer/StudioPlugin.php:72
 Studio\Composer\StudioPlugin->symlinkStudioPackages() at n/a:n/a
 call_user_func() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/EventDispatcher/EventDispatcher.php:176
 Composer\EventDispatcher\EventDispatcher->doDispatch() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/EventDispatcher/EventDispatcher.php:96
 Composer\EventDispatcher\EventDispatcher->dispatchScript() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/Installer.php:323
 Composer\Installer->run() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/Command/UpdateCommand.php:161
 Composer\Command\UpdateCommand->execute() at phar:///Users/moshe.weitzman/bin/composer.phar/vendor/symfony/console/Command/Command.php:242
 Symfony\Component\Console\Command\Command->run() at phar:///Users/moshe.weitzman/bin/composer.phar/vendor/symfony/console/Application.php:843
 Symfony\Component\Console\Application->doRunCommand() at phar:///Users/moshe.weitzman/bin/composer.phar/vendor/symfony/console/Application.php:193
 Symfony\Component\Console\Application->doRun() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/Console/Application.php:251
 Composer\Console\Application->doRun() at phar:///Users/moshe.weitzman/bin/composer.phar/vendor/symfony/console/Application.php:117
 Symfony\Component\Console\Application->run() at phar:///Users/moshe.weitzman/bin/composer.phar/src/Composer/Console/Application.php:100
 Composer\Console\Application->run() at phar:///Users/moshe.weitzman/bin/composer.phar/bin/composer:59
 require() at /Users/moshe.weitzman/bin/composer.phar:24

@XanManZA
Copy link

XanManZA commented Feb 5, 2019

Chiming in here that I am getting the same error as @weitzman

@annikaC
Copy link

annikaC commented Sep 8, 2020

I put together a few fixes from the master branch and some other comments I've seen in the issue queue. My team have been using 0.14.0-beta3 of this package, and have had no issues with "seems not been installed" errors. We've also resolved the need for dump-autoload, and we can install/create symlinks with composer install quite happily. https://github.com/annikaC/studio-fixed

@cobhimself
Copy link

@annikaC, have you perchance created a PR with some fixes @franzliedke might consider?

@annikaC
Copy link

annikaC commented Apr 9, 2021

Yep, these fixes were made before Composer 2 came out. Will have to reroll over the latest master.

@BraunLukas
Copy link

Still no usable fix? :(

@ouun
Copy link

ouun commented Oct 7, 2021

This is so useful! I really appriciate all the work Studio got in the past. But also for me, it is daily frustrating to clean up studio.json before pushing. @franzliedke do you see any chance to make this a bit more comfortable?

@SanderSander
Copy link

This is so useful! I really appriciate all the work Studio got in the past. But also for me, it is daily frustrating to clean up studio.json before pushing. @franzliedke do you see any chance to make this a bit more comfortable?

I have my own composer-link https://github.com/SanderSander/composer-link which tries overcomes the issues.

@ouun
Copy link

ouun commented May 4, 2022

@SanderSander I was just able to test your composer-link package and it is awesome! Thank you so much for the note. Now looking forward to have wildcard folder support. For everyone here who needs a simple and fast solution to link Composer packages from different paths, have a look at this.

@christianlerch
Copy link

We've been struggling with this as well and created a new Composer plugin https://github.com/ALDIDigitalServices/ComposerPackageDevelopmentToolset. Feedback appreciated.

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