Nice new addition by Packagist:
If you’re selling PHP packages, the easiest way to offer Composer package installation to your customers is now “Private Packagist for Vendors”. You get a unique URL and authentication token for each customer and they can use these in their
composer.json
file to install your packages. Especially if you’re still sending zip files to your customers, there is really no reason anymore not to to offer Composer installations.
You can use their our API to integrate “Private Packagist for Vendors” with your existing PHP package shop: Create a customer, grant the customer access to the package, and then get the info needed to send to the customer — all using their API.
// 1. Create Customer
$customer = $client
->customers()
->create('Acme Web Inc.');
// 2. Grant access to package for customer
$client->customers()->addOrUpdatePackages(
$customer['id'],
[[
'name' => 'my-vendor/cool-package',
'versionConstraint' => '^1.0',
'expirationDate' => strtotime('+1 year'),
]]
);
// 3. Get info to send to user
$info = $client->customers()->show($customer['id']);
// …
// 'composerRepository' => [
// 'url' => 'https://my-vendor.repo.packagist.com',
// 'user' => 'token',
// 'token' => 'a6addb89a67b2822d352d113',
// …
As you can see in the code above, customers their access can be locked to specific versions and also limited in time.
Packagist Blog: Introducing Private Packagist for Vendors →
Private Packagist for Vendors →
I’d like to try my hand at a business selling private composer packages. Preferably, I would like to let the developers use my code if they bought a license, but I don’t want them to be able to view the raw source code in the “vendor” directory.
If there is code that must be downloaded to their repo to use, I’d prefer it to show up as a garbled mess that only the assembly of whatever interpreter they’re using can understand.
Is this possible with current implementation of Private Packagist?