On the SitePoint PHP blog editor Bruno Skvorc has posted a tutorial showing you how to set up the Packagist alternative, Satis, in a local network configuration instead of requiring users to still access the external web.

While preparing my technical materials for WebSummerCamp, I realized my workshop would rely on a fairly stable internet connection, as we’d have a lot of ground to cover and a lot of packages to install. Rather than rely on the gods of live demos, or pre-installing everything and ruining the experience, I picked another route.

In this post, I’ll show you how to set up a local Satis instance and have it host the packages over the network it’s currently on, so that everyone who’s also connected to it can put the address into composer.json as a custom repository source, and retrieve all packages from your machine locally – no internet connection required!

He then shows you how to set up the system on a Homestead Improved VM locally, cloning Satis inside of it. He includes an example of the configuration of his required packages and how to build the local repository using this setup. Then, using the built-in PHP web server, he shows the result of the setup and how to access it from other machines. Finally, a few updates are required to the user's composer.json to use the local versions instead of the normal remote connection for the package downloads.

Composer has definitely made a huge impact on how PHP packages and libraries are integrated into other applications. Sometimes, though, it makes more sense for you to keep your code internal to the organization rather than have it public where Composer can install it. In this case, using some thing like Satis (a self-hosted Packagist-ish server) makes more sense.

We all love Composer. It changed dramatically the way we build PHP applications, based on small and reusable components, but this creates new challenges, especially when we have a single point of failure (SPO). With Satis, the deployment process can be made robust by adding redundancy in all potential SPOFs (Packagist and GitHub). Let’s see how it works.

They start with a brief look at how Composer works for those not familiar, making the connection with Packagist and ultimately the public repository. In the context of the "single point of failure" they talk about Packagist being down and it preventing the install (or deployment!) of your application. Satis is prefect to help prevent this. The article then shows how to install Satis (via Composer, naturally) and how to set up the configuration file to define the repositories. The server is then built and can be run using the built-in PHP server on the port of your choice. They include a screenshot of the end result and a quick example of how to use it via your project's Composer configuration.

Stephan Hochdörfer has a new post with a handy tip on speeding up the indexing Satis does on your local repositories to generate its information. His tip involves being more selective in the rebuild process, only indexing the projects that might need it.

In the last couple of months this [indexing] process takes quite a while because Satis rebuilds the index for every repo it knows about. Since we deal with quite a few repos containing a large amount of versions it slowed down the "build time". Obviously it does not make any sense to run Satis on a repo that has not changed. Since Satis was lacking this feature I started hacking on it and I am happy that the feature got merged into master this morning.

With his patch, you can specify only the repository you want reindexed via the "build" command. You can even specify multiple repositories to rebuild, allowing for a bit more automation around the process.

Anyone who has worked with Composer for PHP package management knows that it's been one of the biggest changes in the PHP ecosystem in recent years. Unfortunately, it does have one major potential downfall - it's reliance on GitHub. While GitHub usually does a good job of staying stable, even they falter from time to time. Thankfully there's a locally hosted alternative you can use - Satis. In this new post to NetTuts.com, they show you how to use this tool and mirror packages for your own use.

In this tutorial we will set up a local mirror to proxy all your packages required in your project’s composer.json file. This will make our CI work much faster, install the packages over the local network or even hosted on the same machine, and make sure we have the specific versions of the packages always available.

They start with a look at what Satis is and how it fits into the whole Composer installation process. From there, they show how to get it installed (via Composer) and using a "mirrored-packages.conf" configuration file to point to the repositories. They include the steps to get it up and running in Apache and show a simple command to get the latest versions for the mirrored packages (perfect for a cron job). There's also some testing included there at the end, parsing and validating the configuration file.

Stephan Hochdörfer has shared a handy tip for the Composers users out there that may have to deal with username/password protected repositories as a part of your package install process. In his post he shows how to use a simple "expect" script to automatic the HTTP Basic Auth login.

A couple of months ago when we set-up our own internal Satis repository to host our custom Composer packages. We ran into an "unpleasant" issue with Composer that had this PR as an result. To sum things up: We are using HTTP Basic Auth to password-project our Satis repository. There was no way we could switch to an SSL client certificate to allow Composer to authenticate itself automatically without asking for a password. Asking for the password on a developer`s machine is no big thing, but it since we need an automated Composer run in our Jenkins environment, there was no way to set things up.

As Composer doesn't currently support this functionality, they had to find a way around it. They went with an expect script that is used to work with the prompts and send the username/password information when expected. He also points out that this could be useful for other situations and tools - like a Bower build.

One of the major recent advancements in the PHP ecosystem has been the use of Composer (and the Packagist service) for package and dependency management. Unfortunately, this default setup comes with one big limitation - if the Packagist or Github are unavailable for some reason, your Composer install will fail, possibly leaving you dead in the water. So, what can you do to help? On the Qandidate.com blog today they introduce you to Satis and how to integrate it into your deployment process.

If you're familiar with Composer you know it can be slow and sometimes unreliable when one or more packages are not available. Every time you run composer update Composer will access Packagist to check for new versions of the packages you use. When it finds new releases it will access GitHub, BitBucket (or wherever the packages are hosted) to download your packages.

Satis is a "private Packagist" and provides the data Composer needs to fetch and integrate either your internal packages or mirrors of external ones you've created. They help you get it installed, configured and show how to build and serve up the information via PHP's own built-in web server. They also touch on a few other related points - the speed of Satis, reliability and some concerns around securing your installation.

On the VG Tech blog today there's a post that show you a way to reduce your dependencies on Composer (using Github) without sacrificing the use of the tool.

Composer is the defacto standard dependency manager for PHP out there, also here in VG. [...] For the most parts it has been a pleasant experience, but it creates a hard dependency towards external sources as we now require these sources to be available when updating/installing. [...] Since we use Composer for all our internal packages, we already had Satis set up, which basically is a package repository builder for Composer.

They include their Satis configuration and link to more information about the archive feature to bring a mirror of the repo in-house easily. There's also an example of the "require" section that defines the packages and version numbers you're expecting.