Imager breaks installation for Imager::File::PNG

[KES777]

perl-carton/carton#282 (comment)

[tonycoz]

cpan Imager::File::PNG installs successfully for me in a clean perl, including successfully installing Imager.

It's deliberate that installing Imager installs Imager::File::PNG if possible.

[tonycoz]

You can prevent installation of the bundled modules by setting IM_ENABLE=none in the environment before trying to install Imager.

This will prevent any of the modules also on CPAN from being built, including FT2, GIF, JPEG, PNG, TIFF, Win32. FT1, T1.

[KES777]

The problem is that Imager installs Imager::File::PNG directly and thus Carton did not notice that installation and does not include Imager::File::PNG modules into cpanfile.snapshot and archive for that modules into bundle.

[tonycoz]

I don't know what you mean by "installs ... directly" - the sub directory modules are installed no differently to other sub-directory modules, such as in Encode or Tk. The only difference is that the Imager dist doesn't "provide" the modules, so that the separate dists will be installed as hard dependencies.

I've described a mechanism you can use to prevent installing Imager trying to install Imager::File::PNG. I won't be changing the default.

[KES777]

If Imager provides Imager::File::PNG it should describe that. Currently it installs that module silently:

  Imager-1.018
    pathname: T/TO/TONYC/Imager-1.018.tar.gz
    provides:
      Imager 1.018
      Imager::Color 1.015
      Imager::Color::Float 1.008
      Imager::Color::Table 1.004
      Imager::CountColor 0.03
      Imager::Expr 1.008
      Imager::Expr::Assem 1.004
      Imager::Expr::Infix 1.008
      Imager::Expr::Postfix 1.008
      Imager::ExtUtils 1.003
      Imager::FORMATS 1.018
      Imager::File::CUR 1.000
      Imager::File::ICO 0.08
      Imager::File::SGI 0.05
      Imager::Fill 1.013
      Imager::Filter::DynTest 0.03
      Imager::Filter::Flines 0.04
      Imager::Filter::Mandelbrot 0.05
      Imager::Font 1.039
      Imager::Font::BBox 1.007
      Imager::Font::FreeType2 1.021
      Imager::Font::Image 1.000
      Imager::Font::Test 1.002
      Imager::Font::Truetype 1.013
      Imager::Font::Type1 1.013
      Imager::Font::Wrap 1.005
      Imager::Fountain 1.009
      Imager::IO 1.018
      Imager::Matrix2d 1.013
      Imager::Preprocess 1.003
      Imager::Probe 1.008
      Imager::Regops 1.000
      Imager::Test 1.007
      Imager::Test::OverUtf8 1.007
      Imager::Transform 1.007
      Imager::TrimColorList 1.000
    requirements:
      Exporter 5.57
      ExtUtils::MakeMaker 0
      Scalar::Util 1.00
      Test::More 0.99
      XSLoader 0

Imager::File::PNG should be inside section provides:

[KES777]

If Imager does not provide Imager::File::PNG why this alien module is inside this distribution? https://github.com/tonycoz/imager/blob/master/PNG/PNG.pm

[tonycoz]

Imager::File::PNG and the other similar modules are part of the Imager distribution because they were historically part of the distribution and installed when you installed Imager if the appropriate libraries (libpng for PNG) were available. They continue to be bundled in the Imager distribution to maintain that behaviour.

The separate distributions were created so another module could reliably depend on them. The separate distributions only successfully install when the appropriate libraries available, so you can depend on them. Installing the Imager distribution itself may not install them, so they aren't provided.

[miyagawa]

This is generally a problematic behavior when a distribution installs modules that belong to another distribution:

➜  curl -s www.cpan.org/modules/02packages.details.txt  | grep Imager::File::PNG
Imager::File::PNG                  0.98  T/TO/TONYC/Imager-File-PNG-0.98.tar.gz

if you install Imager first, Imager::File::PNG gets already installed as part of the process, and dependency managers like Carton/Carmel can't get the right information about the tarball you might otherwise need.

An ideal way to handle this is to split the distributions one step further, so Imager distribution would depend on Imager::File::PNG, like LWP distribution was split into multiple dists, and the core libwww-perl depends on bunch of sub distributions. I can anticipate that it would introduce circular dependencies, unless you make a new Imager-Core distribution, which then Imager would depend on i.e.

Imager
-> Imager::Core
-> Imager::File::PNG
-> Imager::File::JPEG
...

Imager::File::PNG
-> Imager::Core

Imager::File::JPEG
-> Imager::Core

All that being said, it seems you can avoid this behavior with IM_ENABLE=none though - so I suppose you can set that while running carton @KES777

[tonycoz]

Imager doesn't require Imager::File::PNG to successfully install, but the intent is other modules (or non module users) can depend on successful installation of Imager::File::PNG.