Fixing the lock file

[janhartigan]

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": "git@github.com: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]

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]

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]

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]

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]

@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]

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]

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]

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

[janhartigan]

@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]

@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]

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

[swt83]

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]

@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]

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]

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

[swt83]

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]

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

[franzliedke]

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

[swt83]

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]

@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]

@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]

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]

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]

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]

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]

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;
    }

}

[AndrewFeeney]

Any word on this? If there's a way it can be done I'd love to help with a PR. We have a ship terminal command in github.com/arcframework/framework which currently runs composer update so those of us running a local dev build of Arc Framework don't end up with a broken plugin build, but I'd love to contribute a fix so we can switch that to composer install.

[franzliedke]

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. :smile:

[franzliedke]

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. :wink:

[nathanmerrill]

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]

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]

@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]

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]

@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]

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]

@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]

@PapsOu try:

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

https://github.com/franzliedke/studio/commit/d4e19eb48f1313f2aad1c35d06f13de43fef62fa#commitcomment-26333596

[PapsOu]

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

[ElfSundae]

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

[PapsOu]

@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]

@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]

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]

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]

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]

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]

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

[annikaC]

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]

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

[annikaC]

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

[BraunLukas]

Still no usable fix? :(