willdurand / puppet-composer Goto Github PK

the home directory can be changed, but is used directly in the config system. In order to avoid such issues the home_dir should be configurable

Description

When including the composer class, if no version is provided the url the modules loads composer from will include dev/nightly builds (https://getcomposer.org/composer.phar)

Note: there may be no other url avalible that only include non dev builds which may require a major change to the module to use the composer recommended install method
https://getcomposer.org/doc/faqs/how-to-install-composer-programmatically.md

Steps to reproduce

add the composer module to a class/ include it in a manifest and do not provide a url

eg: include composer

Expected behavior

composer module should only load final builds and should not include snapshots/dev builds unless specifically requested

Further details

Ubuntu 16.04 and 14.04
puppet 5.5
Module version
"name": "willdurand-composer",
"version": "1.2.7",

Related issues

there are some packages like "humbug" that can be required globally, this module should have a provider for such a usecase:

package { 'humbug':
    provider => composer,
    ensure   => installed,
}

If I got it right, you can only install the latest version of composer. So if an update of composer is released, puppet does not know what version is installed or if it should update it, does it?

Currently it might not be necessary to specify a specific version of composer. But it should be possible to stick to a specific version of composer or at least force the updated to the latest composer version somehow.

Any plans on integrating this?

Description

Puppet agent errors:
Failed to apply catalog: Parameter cwd failed on Exec[composer-install]: cwd must be a fully qualified path at /etc/puppetlabs/code/environments/production/modules/composer/manifests/init.pp:78

Steps to reproduce

revision 8b97b4e

in a puppet manifest:
include ::composer

Expected behavior

install composer without errors

Further details

from facter:
puppetversion 4.3.1

"architecture" : "x86_64",
"family" : "RedHat",
"hardware" : "x86_64",
"name" : "CentOS",
"release" : {
"full" : "7.2.1511",
"major" : "7",
"minor" : "2"

the composer::project always uses the root account to exec the install and update from composer.
It should be possible to choose the user and group with the composer::project.
Perhaps a default with www-data/httpd should be choosen.

Description

While trying to wget 'https://getcomposer.org/composer.phar' on Debian 8, you get an error because of the SSL certificate of getcomposer.org. The authority path for this certificate is not installed by default on Debian 8:

Notice: /Stage[main]/Composer/Exec[composer-install]/returns: converted 'https://getcomposer.org/composer.phar' (ANSI_X3.4-1968) -> 'https://getcomposer.org/composer.phar' (UTF-8) Notice: /Stage[main]/Composer/Exec[composer-install]/returns: --2016-10-07 10:46:05-- https://getcomposer.org/composer.phar Notice: /Stage[main]/Composer/Exec[composer-install]/returns: Resolving getcomposer.org (getcomposer.org)... 87.98.253.108, 2001:41d0:a:7b19::2 Notice: /Stage[main]/Composer/Exec[composer-install]/returns: Connecting to getcomposer.org (getcomposer.org)|87.98.253.108|:443... connected. Notice: /Stage[main]/Composer/Exec[composer-install]/returns: ERROR: The certificate of 'getcomposer.org' is not trusted. Notice: /Stage[main]/Composer/Exec[composer-install]/returns: ERROR: The certificate of 'getcomposer.org' hasn't got a known issuer. Error: /usr/bin/wget -O /usr/local/bin/composer https://getcomposer.org/composer.phar returned 5 instead of one of [0] Error: /Stage[main]/Composer/Exec[composer-install]/returns: change from notrun to 0 failed: /usr/bin/wget -O /usr/local/bin/composer https://getcomposer.org/composer.phar returned 5 instead of one of [0] Notice: /Stage[main]/Composer/File[/usr/local/bin/composer]: Dependency Exec[composer-install] has failures: true

Steps to reproduce

class {'::composer':
command_name => 'composer',
target_dir => '/usr/local/bin',
}

Further details

Debian 8.6
puppet-composer 1.2.1

Description

According to the readme, the auto_update parameter should cause composer to be updated, when puppet is run.

You can also auto update composer by using the auto_update parameter. This will update Composer only when you will run Puppet.
However this does not work. All this does is add a cronjob to update composer, but there is no update during puppet run.

Steps to reproduce

class { '::composer':
  auto_update => true
}

Expected behavior

Composer is updated during puppet run.

Hello!

Are there any plans on introducing features to support setting global composer config options (the ones that are stored in ~/.composer/config.json)?
Particularly I need to set the github-oauth directive and currently I'm only coming up with hacky solutions :)

Description

About a year ago I started maintaining this and willdurand/nodejs. Since then I've seen several bug reports because of duplicated declarations because of wrongly used package declarations in puppet in our or in other module's code.

Actual issue.

The issue can be seen when having a simple look at the docs: ensure_resource() docs. The ensure_* API only avoids crashes due to duplicated resources if the resource definition passed to the ensure_* API contains the same hash as the already declared resource if declared. So whenever someone uses ensure => installed for instance and another one uses ensure => present (which is the default of the ensure_packages() function) there'll be a crash (we started using ensure => installed as the docs do that as well).

However this causes a lot of issues for other users and any change in a minor or even a patch release could be a BC break because of this although there's no real API change.

Steps to reproduce

# class1.pp
class class1 {
  ensure_packages(['wget'])
}

# class2.pp
class class2 {
  ensure_packages(['wget'], {
    ensure => installed,
  })
}

Execute both of them and you'll get a duplicate resource failure during the catalog compilation:

Error: Evaluation Error: Error while evaluating a Function Call, Duplicate declaration: Package[wget] is already declared; cannot redeclare at /tmp/vagrant-puppet/environments/dev/manifests/site.pp:9:3 on node localhost.sbde-40936.btopenzone.com

Expected behavior

We need an approach how to avoid such declarations without receiving a bug report all two months.

Notes to this topic

I think that this approach contains several issues because of a simple issue: many puppet modules require extra-packages that they aren't actually responsible for (in this case wget although this module installs composer, the nodejs module needs a gcc compiler and tar and wget as well), so it's quite likely that such collisions might happen.

Related issues

#43, #41, willdurand/puppet-nodejs#168, willdurand/puppet-nodejs#39

Possible solutions

do the if !defined(Package['foobar']) way

I reverted this in willdurand/nodejs already because I'm not a big fan of these bloated statements that messed up the code in the current oldstable 1.x versions of that module.

revert the changes

I think that this is the best approach (also suggested in several comments last week) although the docs propose the use of ensure => installed.
However I think that this just fixes the symptom.

Imagine the following case:

class class1 {
  if !defined(Package['wget']) {
    package { 'wget':
      ensure => installed,
    }
  }
}
class class2 {
  ensure_packages(['wget'])
}

class { '::class1': } ->
class { '::class2': }

If a module uses the ensure => installed approach and our code gets compiled after theirs (as shown in the example) these guys would have a problem as well:

Error: Evaluation Error: Error while evaluating a Function Call, Duplicate declaration: Package[wget] is already declared in file /tmp/vagrant-puppet/environments/dev/manifests/site.pp:6; cannot redeclare at /tmp/vagrant-puppet/environments/dev/manifests/site.pp:12:3 on node localhost.sbde-40936.btopenzone.com

Therefore I suggest to revert these changes regarding ensure => installed in both modules (as mentioned in some comments), but add another parameter to the init.pp class for these cases which avoids execution of these module setup if something still causes crashes.

class { '::composer':
  # all the other settings
  build_deps => false,
}

This would skip the entire package setup if there are any further problems.
Same with willdurand/nodejs:

class { '::nodejs':
  # all the other settings
  build_deps => false,
}

So reverting the changes should (hopefully) resolve most of the issues and in the remaining, rare cases you could do all the package setup on your own and tell the module to skip that.

currently we're enforcing that the user uses wget as install method.
The install process should be refactored, so curl and wget are possible

There is a symlink in the spec folder ( specifically, spec/fixtures/modules/composer ) after installing this module via librarian-puppet. I'm not sure if it shows up via other installation methods.

This symlink breaks Packer builds, but doesn't affect regular Vagrant builds. Not sure if it affects other uses of Puppet.

Description

using ::composer::config causes the resource to update every puppet run

Steps to reproduce

  class { 'composer':
    user    => 'composer_user',
    require => User['composer_user'],
  }

  ::composer::config { 'composer-config':
    ensure  => present,
    user    => 'composer_user',
    configs => {
      'github-oauth' => {
        'github-server.example.com' => $deploy_key,
      },  
    },  
    require => Class['composer'],
  }

then

$> puppet agent -t
...
Info: Applying configuration version '1458917059'
...
Notice: /Stage[main]/Foo::Development/Composer::Config[composer-config]/Composer::Config::Entry['github-oauth'.'github-server.example.com'-composer_user-create]/Exec[composer-config-entry-'github-oauth'.'github-server.example.com'-composer_user-present]/returns: executed successfully
Notice: Finished catalog run in 5.58 seconds

Expected behavior

This should only run when that config is changed manually outside of puppet, instead it runs evertime

Further details

OS: Ubuntu 14.04
Puppet version 3.4.3
Facter version: 1.7.5
Version of this module is the master branch from git (642812a at the time of this issue being opened)

Description

default home directory for root user is incorrect

Steps to reproduce

include composer
::composer::config { 'composer-config':
  ensure => present,
  user     => 'root',
  configs => {
    'github-oauth' => {
      'github.com' => $::magical_oauth_key,
    },
  },
}

Expected behavior

auth.json should be generated and stored in /root/.composer/auth.json

Actual behavior

File is created at /home/root/.composer/auth.json

$> ls -l /root/.composer/auth.json
ls: cannot access /root/.composer/auth.json: No such file or directory
$> cat /home/root/.composer/auth.json 
{
    "http-basic": {},
    "github-oauth": {
        "github.com": "TOKEN"},
    "gitlab-oauth": {}
}

Further details

This seems to be where the issue is manifests/config/entry.pp:25

  $home_dir = $custom_home_dir ? {
    undef   => "/home/${user}",
    default => $custom_home_dir,
  }

Related issues

If you're aware of other issues or even issues in other libraries being used by this package then you should reference them here as they may help to solve the issue.

class composer($version = 'UNDEF') {}

should be

class composer($version = undef) {}

Description

Really minor issue.
Adding config to user root without specifying home_dir creates /home/root and places config there.

Steps to reproduce

classify node with:

class { '::composer': }

::composer::config { 'composer-root-config':
  ensure   => present,
  user     => 'root',
  configs  => {
    'github-oauth' => {
      'github.com' => 'key'
    },
  },
  require  => Class['::composer']
}

Expected behavior

Root is pretty default user in every linux distribution.
And there is fact root_home with proper value
It is possible to get users home dir via puppet.

Probably I can do PR if this is accepted behavior :)

Using the following (with v1.2.5 on Debian Jessie, Puppet 4.3.2):

  class { '::composer':
    auto_update => true,
  }

Produces the error:

==> default: Error: /Stage[main]/Composer/Exec[composer-install]: Could not evaluate: Could not find command '/usr/local/bin/composer'

Reverting to v1.2.4 results in the expected:

==> default: Notice: /Stage[main]/Composer/Exec[composer-install]/returns: executed successfully

There are several usecases where the composer cache hides dependency conflicts. In such cases everything keeps working, but those issues are hard to reproduce/fix.
In order to avoid such issues, a tool like the auto-updater should be created for the clear-cache command.

as this module is responsible for composer and not for php management, the user has to maintain the relationship between the two packages him-/herself.
The current example in the docs is too complex as there are even simpler solution to tackle the installation of php and composer in the correct order.

this module is currently able to download the composer executable and place it into a directory, usually /usr/local/bin.
A quite useful feature would be to tell puppet that composer should install dependencies and setup projects. There's some pseudo code how such a feature could look like:

The most basic feature would be a setup inside a directory:

::composer::project_setup { 'app-composer-setup':
  cwd      => '/var/www/app_name',
  no_dev   => false, # default true
  options  => '--prefer-source',
  user     => 'vagrant',
}

Creating projects from scratch (composer create-project) should be also possible:

::composer::project_setup { 'symfony-app':
  cwd          => '/var/www/app_name',
  user         => 'vagrant',
  project_name => 'symfony/framework-standard-edition',
  constraint   => '^3.0',
}

When setting up a machine it should be also possible to setup a single dependency:

::composer::dependency { 'project-symfony':
  ensure          => present,
  cwd             => '/var/www/project_dir',
  user            => 'vagrant',
  dependency_name => 'symfony/symfony',
  constraint      => '^3.0',
  no_dev          => false,
  no_update       => true, # default false
  options         => '--prefer-source',
}

Setting up global dependencies may be possible, too:

::composer::dependency { 'global-phpunit':
  ensure          => present,
  global          => true,
  user            => 'vagrant',
  dependency_name => 'phpunit/phpunit',
  constraint      => '^5.1',
  options         => '--prefer-source',
}

Changing the ensure parameter (default present) to absent, the dependency will be removed by composer.

Description

Puppet fails to apply catalog. It outputs en error of a duplicate package (wget) declaration from init.pp, with willdurand/nodejs/manifests/instance/pkgs.pp (so both modules are using ensure_packages function from puppetlabs/stdlib).

Steps to reproduce

Create Composer and NodeJS resources with willdurand/composer (1.2.2) and willdurand/nodejs (2.0.0-alpha1). Both require puppetlabs/stdlib >= 3.2.1 (version 4.14.0 was used).

Further details

I managed to solve this issue by changing init.pp on line 53 from:

ensure_packages(['wget']) to ensure_packages(['wget'], {ensure => 'installed'})

... which I think is strange, as this second (optional) argument is always merged with ensure => 'present', and I can read from Puppet docs that for the ensure attribute...

Valid values are present (also called installed), absent, [...]

So obiously it should be a Puppet issue, but as I'm really not a Puppet expert, I prefered to open this issue and share this simple workaround.

Description

This dependency will help to validate the parameters properly and to utilize the validation logic.

Description

Parameter unless failed on Exec[composer-install]: 'test -s '/usr/local/bin/composer'' is not qualified and no path was specified. Please qualify the command or specify a path.

I tracked it down to line 80 in init.pp in the following exec resource where test does not have a fully qualified path.

exec { 'composer-install':
command => "/usr/bin/wget -O ${composer_full_path} ${target}",
user => $composer_user,
unless => "test -s '${composer_full_path}'",
timeout => $download_timeout,
}

Steps to reproduce

include composer

I resolved it by adding an exec resource reference to set path in my manifest.

Exec {
path => '/bin,/sbin,...',
}

include composer

Should the module provide the fully qualified path to the test executable used in the exec resource or do I need to include the resource reference?

Description

When indicating custom target_dir module installs to that directory and additionally to /bin

Steps to reproduce

Classify node with (in my case it is centos7)

class { '::composer':
  command_name => 'composer',
  target_dir   => '/usr/bin'
}

# whereis composer
composer: /usr/bin/composer

# which composer
/bin/composer

Expected behavior

Should locate composer in /usr/bin only

Further details

For test: Prior to classifying node with composer i'm deleting files in both location /bin and /usr/bin

After classification finished files again appear in both locations

In my case there is issue with

  ensure_packages(['wget'], {
    ensure => installed,
})

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Function Call, Duplicate declaration: Package[wget] is already declared in file /etc/puppetlabs/code/environments/development/modules/sysadmin/manifests/base.pp:2; cannot redeclare at /etc/puppetlabs/code/environments/development/modules/composer/manifests/init.pp:53 at /etc/puppetlabs/code/environments/development/modules/composer/manifests/init.pp:53:3

i'm controlling what software is installed on my nodes.
If there is need in some basic packages i'm using my own sysadmin::base which has couple packages like git, wget, vim, rsync, ...
Installing them with ensure_packages($packages_list)
and it not interferes with modules which have explicit packages install for example ensure_packages(['git']) or 'wget'.

In your case I don't understand why you have to use ensure_packages() with ensure => installed
do it like so if you want

package{ 'wget':
  ensure => installed,
}

But of course i'm here to suggest you to use simple form ensure_packages(['wget'])

Probably you will agree with me that it looks like nonsense: many puppet users have wget installation in their own modules/manifests and why they should be distracted with some module from forge which is not directly related to wget. Users which are using puppet should be smart enough to fix wget package on their systems, and use ensure_packages() for some trivial cases in manifests

Description

When using puppetlabs-stdlib-4.25.1 deprecation notices are triggered due to the use of both validate_bool and validate_string functions

Steps to reproduce

composer and stdlib modules installed.

Expected behavior

no notices, warnings, or errors

Further details

puppet version 4.5.1
ubuntu 16.04

==> delengtest: Warning: This method is deprecated, please use the stdlib validate_legacy function,
==> delengtest:                     with Stdlib::Compat::String. There is further documentation for validate_legacy function in the README.
==> delengtest:    (at /etc/puppetlabs/code/modules/stdlib/lib/puppet/functions/deprecation.rb:28:in `deprecation')
==> delengtest: Warning: This method is deprecated, please use the stdlib validate_legacy function,
==> delengtest:                     with Stdlib::Compat::Bool. There is further documentation for validate_legacy function in the README.
==> delengtest:    (at /etc/puppetlabs/code/modules/stdlib/lib/puppet/functions/deprecation.rb:28:in `deprecation')

Related issues

If you're aware of other issues or even issues in other libraries being used by this package then you should reference them here as they may help to solve the issue.