News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Matthias Noback:
There's no such thing as an optional dependency
April 11, 2014 @ 11:19:19

In his latest post Matthias Noback suggests the idea that there's no such thing as an optional dependency when it comes to working with packages and Composer.

On several occasions I have tried to explain my opinion about "optional dependencies" (also known as "suggested dependencies" or "dev requirements") and I'm doing it again: "There's no such thing as an optional dependency." I'm talking about PHP packages here and specifically those defined by a composer.json file.

So that everyone's on the same page, he starts with an example of a true dependency in a sample adapter class. He asks the usual question - "what's needed to run this code?" - and looking a bit deeper at the "suggested" packages. As it turns out, some of these dependencies turn into actual requirements when you need certain features of the tool. He points out that this is a problem with quite a few packages in the Composer ecosystem and proposes a solution - splitting packages based on requirements. He gives an example based on his adapter with a Mongo requirement split off into a "knplabs/gaufrette-mongo-gridfs" package that's more descriptive of the requirements.

0 comments voice your opinion now!
optional dependency composer packagist suggested package

Link: http://php-and-symfony.matthiasnoback.nl/2014/04/theres-no-such-thing-as-an-optional-dependency/

Gary Hockin:
Less is More
April 07, 2014 @ 09:56:36

Gary Hockin has a new post to his site talking about how he's found that less is more when it comes to what to include in your "composer.json". He works through some of his own opinions on the matter and suggests a bit more thought before just including another library.

I have absolutely no doubt this post will be largely disagreed upon by many in the PHP community, but I've had a terrible day and I'm hoping that the process of just getting this off my chest will be therapeutic in some way. [...] So, today I sat down and started writing the tests for our new lightweight SDK that offsets much of the work needed in the delivery of the adverts to workers via a Beanstalk queue. It should have been so easy. Things went well for the early part until I realised that I wanted to be able to extract and serialise our Device object to put it into the queue, and then hydrate it back into a Device object inside the worker

He assumed that since he'd used Zend Framework 2 a good bit and there were no (declared) dependencies, he could directly use an individual component. Unfortunately, there was a dependency (ZendFilterChain), requiring another package to be added via Composer and pulled down. He points out that Composer has made this almost too easy and developers maybe aren't as thoughtful about the libraries they pull in because of it.

He makes a call out to developers to remember the idea behind the MicroPHP Manifesto and really think about the code they're puling in, how large it is and if it's what they really need. He's not suggesting that Composer is the problem, rather the blind usage of it without thinking through the implications.

0 comments voice your opinion now!
less more library composer packagist include

Link: http://blog.hock.in/2014/04/05/less-is-more

Pádraic Brady:
PHP Package Signing My Current Thoughts
March 10, 2014 @ 11:57:49

Pádraic Brady has a new post sharing some of his ideas around PHP package signing and a few possible ways to approach (and possibly solve) the problem.

We figured out how to write good code. We figured out how to write good code in a reusable way...for the most part. We figured out how to distribute and mix all that good reusable code in a sensible fashion. Can we now figure out how to do it all securely? [...] The problem with package signing from my perspective is tied up in a phrase most of you would know: The needs of the many outweigh the needs of the few. Thank you, Spock.

He compares two different alternatives, Public-key infrastructure (PKI) vs (Pretty Good Privacy) GPG, and how the idea of trust fits into the picture. He also points out an unfortunate fact when it comes to the initial adoption of package signing methods - people are lazy (and cheap). They want to get things done and not have extra steps. Signing their packages would be one of these steps. He suggests an alternative, though, using double signatures to verify the integrity and validity of its contents. He also talks about the role that metadata plays in the overall package ecosystem and how signing it as well could be part of the solution.

0 comments voice your opinion now!
package signature signing metadata packagist composer

Link: http://blog.astrumfutura.com/2014/03/php-package-signing-my-current-thoughts

Matthias Noback:
PHP - The Future of Packages
January 22, 2014 @ 09:04:03

In a recent post to his site Matthias Noback looks at what he sees as the future of packages in PHP including some thoughts about the offerings on PHPClasses.org and the rise of Composer/Packagist.

When you ask me: what is the reason for a PHP developer to write classes? I answer: in order to separate responsibilities and hide data. Many principles have been devised to help developers fulfilling these tasks. But in most cases there was no sign of these principles underlying the code on phpclasses.org. This is why many people have turned their back on phpclasses.org. I was about to do the same. But in response to my tweet some people, including Manuel Lemos, responded that everybody needs a place to learn and try.

He looked a bit more into the PHPClasses site and found some new features not known about (including Composer support). He points out some issues with their approach about publishing packages and how they're released. He contrasts this with how Packagist.org handles the Composer information and package statistics. He looks at some recommended ways to judge the quality of packages and mentions a new book he's writing to help PHP developers create better, more useful (and flexible) packages.

0 comments voice your opinion now!
future packages phpclasses composer packagist

Link: http://php-and-symfony.matthiasnoback.nl/2014/01/php-the-future-of-packages

Qandidate.com:
Using Satis for fast and reliable software deployment
December 05, 2013 @ 11:57:32

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.

0 comments voice your opinion now!
satis introduction packagist composer alternative private package

Link: http://labs.qandidate.com/blog/2013/12/05/using-satis-for-fast-and-reliable-software-deployment/

Zend:
Apigility Progress report zf-mvc-auth, packagist, and PHP's built-in web server
November 01, 2013 @ 15:52:11

In a new post to the Apigility forums today Matthew Weier O'Phinney has announced the release of an authentication/authorization component for the recently announced project from Zend. Apigility is a Zend Framework-based tool for easily constructing and managing an API.

We've been working hard on Apigility since ZendCon, and have released some more code into the wild. zf-mvc-auth exists to provide both authentication and authorization for your APIs; in fact, it's a bit of a general-purpose library for ZF2 MVC apps! Right now, we support HTTP basic and digest authentication out of the box, and will be working next on OAuth support. Authorization is done by default via ZendPermissionsAcl, as we discovered a problem with using RBAC: RBAC is deny-by-default, which does not work when you want an open-by-default schema. You may opt-in to deny-by-default, as well as mark individual services as requiring permission by default. Finally, you have the option of denying/allowing per HTTP method of a service as well.

You can find out more details about this functionality in this quick screencast. The zf-apgility module depends on this new zf-mvc-auth module, so it will be included and available by default in your APIs. In that same post Matthew also talks about the listing of the Apigility packages on Packagist service and a note for those wanting to use the built-in HTTP server to run the tool (a PHP version dependency).

0 comments voice your opinion now!
apigility progress zendframework mvc authentication authorization packagist http server

Link: https://groups.google.com/a/zend.com/forum/#!topic/apigility-users/_mOPkxxmGYI

PHPMaster.com:
Listing Packages on Packagist for Composer
April 24, 2013 @ 11:57:49

Composer has changed how PHP developers work with external libraries and packages in even just the small amount of time its been around. One of the keys to its use, though, is getting your code listed on the Packagist site for easy requesting. In this new tutorial on PHPMaster.com, they walk you through doing just that.

You've created an awesome library, and now you're ready to open source it and share it with the world. Hopefully someone else can benefit from your work, and maybe you'll even receive a bug report or patch to make the library even better. But none of that can happen unless people can find itů and the modern way is increasingly becoming through Composer and Packagist. In this article I'll show you what information is needed in your composer.json file and how to list your library on Packagist so others can easily find it.

He talks some about the "composer.json" file for your project and talks some about the content that has to be there for Packagist to be able to pick it up correctly. He then shows you how to go over to the Packagist website, log in and add a package to their repository. It then shows you where on Github you'll need to go to set up a Service Hook to talk back to Packagist when a new version is deployed.

0 comments voice your opinion now!
listing package composer packagist tutorial repository

Link: http://phpmaster.com/listing-packages-on-packagist-for-composer

Matthias Noback:
Experiences with PHP Open Source Software in a Symfony-Friendly Environment
November 14, 2012 @ 11:24:19

Matthias Noback has a new post today sharing some of his experiences working with Open Source software, specifically as it relates to this dealings with a "Symfony-friendly environment".

These days, good PHP object-oriented libraries are all around and easily available. To me, it is actually thrilling to be part of this flourishing community, while working with Symfony2 and blogging about the Framework, the Components and their neighbors (like Silex). [...] Still, to me, contributing felt like too big a step to take right now. Until a few weeks ago, when I was looking for something I needed (a PHP client for the Microsoft Translator API) and could not find a decent solution. I decided to make it myself, and share it online.

He shares his "checklist" of steps he followed to get the library up and working (less about the library and more about the process):

  • Write the code
  • Initialize a Git repository
  • Add a composer.json file
  • Add unit tests
  • Make it open source and developer friendly
  • Push your code to GitHub
  • Register your project at packagist.org
  • Register the Packagist Service Hook
  • Versioning
  • Continuous integration using Travis CI

He also suggests that, at least at the outset, you skip some of your tests that might rely on external data sources/resources (so the build can start as green on Travis) then coming back and refactoring to mock things out correctly. It might look like an intimidating list for a beginner, but it's a great process to follow to have a robust, effective development/deployment process.

0 comments voice your opinion now!
opensource software process checklist github composer unittest travisci packagist


DZone.com:
Including PHP libraries via Composer
March 27, 2012 @ 09:02:55

On DZone.com there's a new post from Giorgio Sironi about using Composer to install packages/libraries:

The main package source used by Composer seems more similar to the usage of git submodules at a first glance: a list of dependencies on other projects is specified and stored under version control, and upon a checkout these projects are grabbed directly from their repositories.

He talks about what problem the project solves, what issues he's found with it so far (the amount of stuff downloaded for each dependency, the single point of failure of the one Packagist repository) and shows how to get it installed and creating a sample "composer.json" file for an example project.

0 comments voice your opinion now!
include library package composer packagist introduction


Phil Sturgeon's Blog:
Packages The Way Forward for PHP
March 07, 2012 @ 08:29:57

In this new post to his blog Phil Sturgeon talks about what he (and apparently several others) think is the "way forward for PHP" to make it a better language and ecosystem - packages.

What is a package? A package is a piece of reusable code that can be dropped into any application and be used without any tinkering to add functionality to that code. [...] Most package systems also allow for something called dependencies. [...] This is how most modern programming languages work, but to make a generalisation: PHP developers hate packages. Why? Well while other languages have great systems like CPAN for Perl, Gems for Ruby, PIP, PHP has had a terrible history with package management going back years.

He talks about one of the main current packaging systems, PEAR, and how, despite its attempts, it just hasn't seen the adoption the package management of other languages has. Phil makes a recommendation that is slowly becoming more and more popular in the PHP community - building "unframeworks". These sets of reusable components (similar to the ideas behind Aura, Symfony and Zend Framework 2) are designed to be dropped in and used without the dependencies of the frameworks they live in. He points to the Composer/Packagist dynamic duo as a way through all of the current packaging issues - a simple way to make any project an installable package just by adding a configuration file.

0 comments voice your opinion now!
packages composer packagist pear community support unframework



Community Events





Don't see your event here?
Let us know!


list release unittest threedevsandamaybe configure interview podcast wordpress framework application introduction symfony library developer series install community language code api

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework