"Dependency cache keys not yet generated"

[luebbert42]

When I run php app/console assetic:dump in Symfony 2.3.7 I am getting the following error message:

[Sp\BowerBundle\Bower\Exception\RuntimeException] Dependency cache keys not yet generated, run "app/console sp:bower:install" to initiate the cache: Cached dependencies for "/Users/luebbert/tmp/Symfony/app/cache/dev/sp_bower" not found, c reate it with the method createDependencyMappingCache().

I did the following to reproduce the problem with a fresh Symfony 2.3.7 project:

• php composer.phar create-project symfony/framework-standard-edition demo 2.3.*
• php app/console generate:bundle
• created AcmeFooBundle
• followed the install documentation for the spPowerBundle (did not do step 7, as it seems to be optional)

I can upload the demo project if this helps. This issue is not urgent, was mainly playing around with the bundle :-)

[Spea]

Looks like the documentation is not complete, all you have to do is running app/console sp:bower:install ;)

[luebbert42]

yes, this works. but when I try to run app/console assetic:dump I get the error message listened above.

[luebbert42]

and: the install docs are quite good - clear and easy to follow :-)

[Spea]

I followed the same steps and can not reproduce it, maybe you can upload your example somewhere?

[luebbert42]

Probably something stupid I have done wrong: http://www.another-showroom.com/demo.tar.gz

Just in case: $ php --version PHP 5.5.5 (cli) (built: Nov 11 2013 08:45:06) (DEBUG) Copyright (c) 1997-2013 The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies with Xdebug v2.3.0dev, Copyright (c) 2002-2013, by Derick Rethans

[Spea]

Extracted it: tried to execute assetic:dump which outputs the above error, but a sp:bower:install fixes it - PHP-Version: 5.5.6. What bower version have you installed?

[luebbert42]

My bower version is 1.2.8

Works for me, too :-) (I thought that I have tried this, well... ;-))

So right now the advice is that you should alway run sp:bower:install after clearing the Symfony cache. Shall I close the issue or do you want to/can you adjust something so this is not necessary?

[Spea]

I already adjusted this, I'm currently in the final testing phase so nothing gets broken. But yeah, you can close this issue :)

[luebbert42]

thanks for having a look at it!!

[ProjectPwnable]

Since this is still present, here's the solution for anyone else on Windows:

1. The problem lies in Doctrine\Common\Cache\FileCache::getFilename() (specifically, the second argument of str_split)
2. Override the getFilename() of Doctrine\Common\Cache\FileCache with the class at the bottom
3. Add the following parameter to your parameters.yml:

sp_bower.filesystem_cache.class: YourBundle\BowerBridge\WindowsFilesystemCache

New class

use Doctrine\Common\Cache\FilesystemCache;

class WindowsFilesystemCache extends FilesystemCache
{
    /**
     * FilesystemCache marks this as private... so we must override
     * @var string[] regular expressions for replacing disallowed characters in file name
     */
    private $disallowedCharacterPatterns = array(
        '/\-/', // replaced to disambiguate original `-` and `-` derived from replacements
        '/[^a-zA-Z0-9\-_\[\]]/' // also excludes non-ascii chars (not supported, depending on FS)
    );

    /**
     * FilesystemCache marks this as private... so we must override
     * @var string[] replacements for disallowed file characters
     */
    private $replacementCharacters = array('__', '-');

    /**
     * @param string $id
     *
     * @return string
     */
    protected function getFilename($id)
    {
        return $this->directory
        . DIRECTORY_SEPARATOR
        . implode(str_split(hash('sha256', $id), 16), DIRECTORY_SEPARATOR)
        . DIRECTORY_SEPARATOR
        . preg_replace($this->disallowedCharacterPatterns, $this->replacementCharacters, $id)
        . $this->getExtension();
    }
}

Note: you have to copy/paste the disallowedCharacterPatterns and replacementCharacters from the parent class, since they are marked private and have no accessors.

[gesof]

run "composer install" again to refresh the cache

Just found the reason in my case: I have the folder mounted with bind and I was launching sp:bower:install from one path while the webserver was running from another path. Internally bower computes a key based on the $config object as a hashcode then uses it to discover if the cache was generated by converting the key into a path and searching for data there. This is a bad approach since, as per my case, the path to the cache directory is different, depending if I am running from command line or from Apache. I'll post a separate bug for this to be solved.