Satis removed packages that it couldn't find

[PatrickRose]

Satis failed to connect to pear when it was building:

$ cd /srv/www/php-pkg.zedcore.com/install && export COMPOSER_HOME=/srv/www/php-pkg.zedcore.com/install && php /srv/www/php-pkg.zedcore.com/install/satis/bin/satis --no-interaction build /srv/www/php-pkg.zedcore.com/install/satis.conf /srv/www/php-pkg.zedcore.com/web
Scanning packages
Initializing PEAR repository https://pear.php.net
PEAR repository from https://pear.php.net could not be loaded. Undefined index: channel
Initializing PEAR repository https://pear.horde.org
The pear-pear.php.net/mail_mimedecode >=1.5.6 requirement did not match any package
The pear-pear.php.net/pear >=1.10.1 requirement did not match any package
Creating local downloads in '/srv/www/php-pkg.zedcore.com/web/dist'
Dumping 'phpunit/phpunit'.
Dumping 'sebastian/exporter'.
Dumping 'phpunit/phpunit'.
Dumping 'phpunit/phpunit'.
Dumping 'symfony/yaml'.
Dumping 'doctrine/instantiator'.
Dumping 'pear-pear.horde.org/horde_exception'.
Dumping 'symfony/console'.
Skipping 'phpunit/phpunit 4.7.x-dev' (is dev)
Dumping 'symfony/debug'.

Since it couldn't connect to PEAR, it's now removed the various pear dependencies from the static file it's generated. I think satis should be doing something different:

• If we can't connect to any one of the repositories, then something has almost certainly gone wrong and we should bail
• If we can't find one of the packages, then something has also probably gone wrong (either the developer mistyped or it was in a missing repository) so we should bail.

If this does get added, I imagine some people would want to force satis to update anyway so adding a --force-on-failure option is probably worth doing.

[PatrickRose]

(Just in case someone finds this later, we were running an old version of satis, so updating fixed the problem we were having. Satis should probably still be helping us not be idiots though)

[alcohol]

This is simply how Satis currently works. The update process is not an atomic transaction. Short term work-around would be to dump the output into a new directory rather than the existing directory, and then manually move the contents if everything went OK.

[PatrickRose]

Are there plans to make satis atomic? I'm not that familiar with the satis code so I don't know how difficult that'd be, though I imagine it's just:

1. Create a temporary directory
2. Do all the update writing to there
3. Move the temporary directory to the install directory

I think purging is what would make life difficult.

[alcohol]

Honestly, there are zero plans for satis. Most, if not all the work done currently, is contributed by volunteers. The application is considered "done" by the @composer team. It works, as originally intended. Any and all extra features are nice-to-have. We definitely accept pull requests :-)

[stof]

the only way to make Satis atomic is to perform the whole build in a separate folder, and then swap folders at the end. Swapping folders is an atomic operation on the filesystem. Even writing to a single file is not. And building in a different folder and swapping the deployment does not require any change in Satis. This can be handled outside it (Satis does not know how you deploy things anyway)

[PatrickRose]

The application is considered "done" by the @composer team. It works, as originally intended. Any and all extra features are nice-to-have.

In that case, can we tag a 1.0.0 release then?

I probably can't justify company time on this but if I have spare time then this is something that would make our lives easier (and probably make everyone's life easier).

[alcohol]

The thing is, there are still quite some issues open that are marked as bug. Though how relevant they still are and whether or not they should hold back a stable release tag, I am not sure. It is hard for me to judge personally. Perhaps a new issue should be raised in which can be discussed which (if any) of the remaining issues should be solved before a stable release can be tagged.