Month: June 2018

Python Environment and Package Installation

I saw a recent XKCD comic that describes the current state of setting up a Python development environment:

The excellent Explain XKCD site covers the point of the cartoon. The issue is the (ongoing) difficult transition from Python 2.x to Python 3.x and the reality that there is no defacto package installation tool. The messiness of Python’s development environment deeply contrasts with the cleanliness and beauty of the actual language.

One interesting and significant effort in approaching the above issue can be found through the PyPi package manager. A great FLOSS Weekly episode had an interview with one of the maintainers of the new PyPi covering its pros and cons.

PHP’s Composer and Package System

In the PHP world – Packgist site is the definite destination for third-party PHP packages. In conjunction with these packages, Composer is the defacto package/dependency management tool. It’s more than a package manager because it focuses on managing packages on a per project basis.

At its core Composer focuses on dependency management and the secondary result is that it also does package management. One problem that arises is the usage of Composer as a pure package installer across a system rather than just a project. As Composer’s documentation states:

By default it does not install anything globally. Thus, it is a dependency manager. however support a “global” project for convenience via the global command.

Composer’s “global” command installs packages in a common central project and this, in turn, can cause major headaches with projects that have packages installed in different locations.

Pantheon’s blog describes this issue (and its solution) really well:

One of the most commonly documented ways for a PHP command line tool to be installed is via the composer global require command. This command is easy to document and easy to run, which explains its popularity. Unfortunately, this convenient function has a darker side that can cause some pretty big problems. The root of the problem is that Composer, by design, manages dependencies on a per-project basis; however, the global command installs everything into a common central project. The upshot of this is that two distinct projects that were never intended to be combined must suddenly share dependencies. In this configuration, it is all-too-common to encounter dependency conflicts that never would have been observed had these applications been installed independently.

The current solution to this is a Pantheon created tool called Cgr. The blog article provides details on its usage and when to use Composer global.

Note: many thanks to the folks on the Poststatus Slack for discussing Composer’s issues and pointing to Cgr.