I am struggling around a wrong usage of composer, for sure.
I set up this repository: https://github.com/alle/assets-merger
I forked the project and was just trying to make it a kohana-module, including all the dependencies.
As for it would need the YUI comporess JAR, I was trying to make just that JARfile as a dependency, and I ended to declare it in the composer.json file (please, look at this).
Once I need to add my new package to a project I add it in the require section as follows:
...
"alle/assets-merger": "dev-master",
...
But the (latest) composer update command says:
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for alle/assets-merger dev-develop -> satisfiable by alle/assets-merger[dev-develop].
- alle/assets-merger dev-develop requires yui/yuicompressor 2.4.8 -> no matching package found.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.
And my story ends here.
How should I configure my composer.json in the https://github.com/alle/assets-merger repository, in order to include it as a fully satisfied kohana-module in other projects?
Some things I notice in your composer.json.
There is a version of that CSS minify available on Packagist which says it is just a copy of the original Goole-Code hosted files, but with Composer: natxet/cssmin. It is version 3.0.2, but I think that shouldn't make a difference.
mrclay/minify is included twice in the packages with the same version. It also is available on Packagist. You will probably already use that (version 2.2.0 is registered, and because you didn't turn of Packagist access, it will be generally available for install unless a version requirement or conflict prevents it).
You are trying to download a JAR file (which is a java executable without and PHP), but try to get PHP classmaps out of it. That will fail for sure.
You did miss the big note in the Composer documentation saying that Composer cannot resolve repositories mentioned in sub packages, only in the root package. That means that whatever you mention in your alle/asset-merger package will not be used if you use that package anywhere else. You'd have to duplicate these repositories in every package in addition to adding the package name itself as "required".
What this means is that you probably avoided missing mrclay/minify because it is available on Packagist, you might as well have added the cssmin by accident, but you definitly did not add YUICompressor.
But you shouldn't add this in the first place, because it is no PHP software. You can however add post-install commands to your projects. All your Composer integration does is download the JAR file. You can do that with a post-install or post-update command. See the documentation here.
Related
I am trying to use Composer to update a Drupal module. After reading a lot, I am presuming that proc_open is disabled in my shared hosting env. If that is the case, can it be enabled for just one hostname or is it server-wide?
"The Process class relies on proc_open, which is not available on your PHP installation."
From the host: Cpanel states the shell php is system wide so we cannot edit it for just this site. (this comes directly from a ticket they used at cPanel)
The module I was trying to update is for Drupal, Webform latest stable version. Not recommended to update with GUI or Manually....
I understand that proc_open is a potential security risk to other hosts but is there ANY workaround short of a dedicated server? Upping the co$t of doing business by a LOT :)
$ composer require 'drupal/webform:^6.2#beta'
./composer.json has been updated
Running composer update drupal/webform
Loading composer repositories with package information
Updating dependencies
Lock file op#drupal/webform (6.2.0-beta1)
Writing lock file
Installing dependencies from lock file (including require-dev)
Nothing to install, update or remove
2 package suggestions were added by new dependencies, use `composer suggest` to see details.
Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead.
Generating autoload files
Hardening vendor directory with .htaccess and web.config files.
41 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Scaffolding files for drupal/core:
- Copy [web-root]/sites/default/default.services.yml from assets/scaffold/files/default.services.yml
- Copy [web-root]/sites/default/default.settings.php from assets/scaffold/files/default.settings.php
Installation failed, reverting ./composer.json and ./composer.lock to their original content.
[Symfony\Component\Process\Exception\RuntimeException]
The Process class relies on proc_open, which is not available on your PHP installation.
I am trying to finish converting a Drupal | 9.3 site and update The Webform Module for Drupal using Composer. A warning appears in Drupals admin-interface that using auto-update has a good chance of failing.... manual update MIGHT work.... and using composer is the recommended way plus, long term... no Composer, not much chance of updating compex modules.
***At bottom of this post, details with the commands and output I received using Composer are viewable.
I'm on shared hosting and the host investigated through cPanel and on to the upstream wholesale provider. "proc_open" is disabled server-wide as it can potentially traverse the entire server skel, a potentialy security risk to other hosts on the shared server. "proc_open" cannot be enabled for just one host on this system or any system that isn't in a dedicated environment.... all alternatives ^$up the cost of operation BIG.
Does anyone know if there is in fact a workaround? All options/feedback greatly appreciated. I know I'm not alone in this. Has anyone successfully done the manual update to Webform 6.2#beta? Long term, manual updates for Drupal Modules are going to become more and more difficult sans composer....
DRUPAL WEBFORM
6.2.0-beta2 released 15 February 2022
Works with Drupal: ^9.2
Install: $ composer require 'drupal/webform:^6.2#beta'
Thank you!
############# #various command/output #################
Lock file op#drupal/webform 6.2.0-beta1
Writing lock file
Installing dependencies from lock file including require-dev
Nothing to install, update or remove
2 package suggestions were added by new dependencies, use composer suggest to see details.
Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead.
Generating autoload files
Hardening vendor directory with .htaccess and web.config files.
41 packages you are using are looking for funding.
Use the composer fund command to find out more!
Scaffolding files for drupal/core:
Copy [web-root]/sites/default/default.services.yml from assets/scaffold/files/default.services.yml
Copy [web-root]/sites/default/default.settings.php from assets/scaffold/files/default.settings.php
Installation failed, reverting ./composer.json and ./composer.lock to their original content.
[Symfony\Component\Process\Exception\RuntimeException]
The Process class relies on proc_open, which is not available on your PHP installation.
TRIED THIS AS WELL
[user#server web-services]$ composer update drupal/webform --with-dependencies
Loading composer repositories with package information
Updating dependencies
Package "drupal/webform" listed for update is not locked.
Nothing to modify in lock file
Installing dependencies from lock file including require-dev
Package operations: 0 installs, 0 updates, 1 removal
Removing drupal/webform 6.2.0-beta1
Deleting modules/contrib/webform - deleted
Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead.
Generating autoload files
Hardening vendor directory with .htaccess and web.config files.
41 packages you are using are looking for funding.
Use the composer fund command to find out more!
[Symfony\Component\Process\Exception\RuntimeException]
The Process class relies on proc_open, which is not available on your PHP installation.
I'm developing a custom recipe using the package packages from chef.
I created a file under the recipes folder called apache.rb.
Then I uploaded the cookbook through berks and I edited the recipes list on one node with recipe["packages::apache"].
When i run the chef-client I got the following error:
could not find recipe apache for cookbook packages
This is the apache.rb located under recipes/ folder:
package 'Install Apache' do
case node[:platform]
when 'redhat', 'centos'
package_name 'httpd'
version '2.2.0'
when 'ubuntu', 'debian'
package_name 'apache2'
end
action :install
end
Can you try knife upload . --force, to make sure the cookbook is really up-to-date on the chef server?
There might be an older version of the cookbook already uploaded (i.e. before you created the apache recipe), and because you've kept the version number in metadata.rb the same, knife (or berks, depending on what you use for the upload) might be skipping the upload, thinking nothing's changed.
UPDATE:
It should be noted that the above should really only be used if you are really sure you want to update the existing version on the Chef Server (e.g. if you are still in development).
Bumping the version number on the cookbook's metadata would be a much better way to solve this problem for production environments, as pointed out by #Tensibai in the comments below.
I'm used to deploy code depending on Composer (PHP's NPM cousing), that sports .json and .lock files. The first one describes the package and your version constraints, and the second one lists exactly what was installed. Always there's a lock file and you run composer install you're sure to receive the same set of packages; running composer update will re-read the json file, install new versions, and update the lock file.
That's awesome for production deployment, since you don't need to checkout your dependencies to your versioning system and you're sure to have the exact same set of dependencies in production as you have in development.
My question is: how to best automate deployment of NPM-dependent code? Is it possible to achieve a method similar to Composer? I've noticed that npm install only installs what's first available in the package.json file. After the first run, i.e. if you change a version constraint you must manually npm update that package - and that would render automate deployment useless, as there's no way to check in to versioning "update this package here to a new version"...
npm shrinkwrap is a analog of composer.lock file. It will generate a npm-shrinkwrap.json, that have all deps with version in it, so you can use it to deploy to production env. Also you can try a various libs from npm to lock versions or search for updates of it without changing packages.json.
I'm having problems following the 'official' recommendation to check in all external dependencies into git (article http://www.mikealrogers.com/posts/nodemodules-in-git.html linked fron FAQ)
How do you make sure that not only top-level dependencies are checked-in? Most npm modules do currently not follow the recommendation. They all have their node_modules in .gitignore . Just Deleting their .gitignore seems risky.
For compiled module the article recommends to check-in only the sources and run 'npm rebuild' and deploy time. Unfortunately 'npm rebuild' does not do a 'clean make' for all modules (despite bugfix https://github.com/isaacs/npm/issues/1872 being included in npm version 1.0.106 i'm using). This means that I have to prevent compile targets from being checked in (otherwise i would have object code compiled for the developer machine on the production machine without being overwritten by npm rebuild). But: how do i do this? Unfortunately the modules don't have a common compile output directory, so just git-ignoring "node_modules//build" and "/node_modules//out/" (as mentioned in this good article eng.yammer.com/blog/2012/1/4/managing-nodejs-dependencies-and-deployments-at-yammer.html won't help in every case.
Short version: how do you make sure that production servers use the exact same version of all dependent modules as you use during development?
UPDATE: there is now npm shrinkwrap which solves the problem of locking down exact dependency versions, even of dependencies' dependencies! More info here.
Checking in node_modules can be problematic, as the environment it's running on may differ from user to user - so what is compiled on some environment may not work on another. Plus it would fill up your changelogs and repositories with 3rd party code. Which I take it is the conslusion you've come to with your short version of the question, so let me address that.
Short version: how do you make sure that production servers use the exact same version of all dependent modules as you use during development?
Inside your package.json, there will be dependencies: {}, if it is not there, then add it. To accomplish what you want, add your dependencies as the key, and their exact versions as the value. E.g. dependencies: { docpad: '2.5.0', mocha: '1.1.0' }
However, generally (it depends on the author) upgrades to the revision number (the x.x.X number) are just bugfixes and safe. You can allow minor changes by doing dependencies: { docpad: '2.5.x', mocha: '1.1.x' } which saves you from having to update your package.json and do a release everytime there is a bugfix release. You can even do things like 2.x if you wish.
This is the solution I've come to use for all of my modules, as it ensures that even 6 months later or whatever the module will still work - whereas doing something like >= 2.0.0 means when v3 of a dependency comes out, your module will probably be unusable at that time. Ensuring you stick to specific versions "guarantees" stability over time.
For reference you can see how I've done it in my open-source node.js modules here
About the .gitignore of your dependencies (in "node_modules"), npm 1.1 ignores the .gitignore files, so that they are not installed;
npm 1.1 will exclude .gitignore files from the things it installs.
npm 1.0 did not have this feature, so you have to be careful about that.
Deleting them recursively is fine:
find node_modules -name .gitignore | xargs rm
But, in npm 1.1, you never have to do this, because it excludes them
from the install automatically.
That's coming from the chief himself (Isaac), and it's here and seems to cover pretty much everything. The "extraneous" problem I have must be something silly I've done, I'll try a clean setup.