I have just installed laravel 4 using composer in my linux os. While it was downloading and installing all the packages it also gave me a lot of suggestions. It asked me to install
symfony/config
symfony/yaml
symfony/dependemcy-injection
symfony/class-loader
symfony/validator
doctrine/dbal
symfony/expression-language
doctrine/annotations
ext-phpiredis
ext-curl
ext-gmp
paer-pear/PHP_Compat
ext-intl
graylog2/gelf-php
raven/raven
doctrine/couchdb
ruflin/elastica
ext-amqp
ext-mongo
aws/aws-sdk-php
rollbar/rollbar
Should I install these things. And if I have to then how would I install them? Thanks in advance. :D
You don't have to install them for Laravel to function any differently. You should only install them if you explicitly plan on using them. The install directions are usually found on the project's github page.
All of those packages can be found on http://www.packagist.com where you will easily be able to find them, see install directions, usage, etc...
To install them, usually you'd just add the appropriate line, usually found in the documentation, to your composer.json file, run composer update and they should automatically be made available to your project.
You got suggestions for both PHP library packages (PHP code) and PHP extensions (C code).
You should only install the PHP libraries if you know you want to use them. The suggestion feature of Composer allows any developer of a package to let Composer announce on update that there might be more software that enhances the library, but is entirely optional. The description next to the package name might have details on why the package could be installed. For example, a library for FTP and HTTP access might want to use existing FTP or HTTP clients, and will announce both as suggestions. If you decide you don't need FTP access, you only require the HTTP client to be used.
You cannot install PHP extensions via Composer. Installing them usually requires some kind of administrator access to the server, and depends on which OS is installed and whether or not it allows to install these extensions as a regular software package, or needs to have the PECL install toolchain available. If a PHP library suggests a PHP extension, then this extension also is completely optional, and you probably will know that if you need that feature (like access to MongoDB), you need the PHP extension as a prerequisite, but are likely to already have it installed (which would skip this suggestion from the list because it is fulfilled).
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 have a pretty common (i guess) problem. Many of my projects utilize nodejs, some for business logic, others only for some building task.
I need to have different runtimes in different projects, one of my electron apps requires node 7.10.0, a typical build suite requires node 8.x.
Now i know - i can use sudo n 7.10.0 or sudo n latest to switch the runtime globally on my computer (For those, who dont know this - have a look at "n")
Anyway, IMO this is not so convenient (some times, i need to rebuild all the modules after switching versions, often i forget to switch and so on). Is there a way of telling node which interpreter to use? Can i use a .npmrc file in a project directory to force a specific nodejs version within that subdirectory?
I searched exactly for this (npmrc node version) but was not lucky enough to find something.
Okay, i found a similar quesion:
Automatically switch to correct version of Node based on project
it seems you can install "avn" and use a .node-version file to do exactly that.
sudo npm install -g avn avn-n
avn setup
then you can create a .node-version file in your project and enter the desired version
echo 7.10.0 > .node-version
Then avn will detect that and activate the correct version
Unfortunately i get an additional permissions error. So to make this work, you need to install/configure "n" to work without sudo/root.
If you're fine with using another tool you could use nvshim.
pip install nvshim # this is all you need to do
It does not slow your shell startup or switching directories, instead moving the lookup of which node version to when you call node, npm or npx by shimming those binaries. More details in the docs.
Source, I wrote the tool.
NVM (Node Version Manager) allow us to use different versions of node quite easily on a single machine. You can have a look at here how to configure and use it.
Volta can used to manage multiple nodejs, npm or yarn versions on different projects on same machine. It's cross-platform.
For example you can run volta pin node#14 in project directory and this will set node to v14 if it exists otherwise it will download and then set it.
More information here https://docs.volta.sh/guide/
When and why should we use the option --no-bin-links when we install npm packages?
The official docs say:
The --no-bin-links argument will prevent npm from creating symlinks for any binaries the package might contain.
But it is still unclear to me for which scenarios we have to specify this.
What will be the impact of the specifying of this option on the functionality of the package? Will the package when used error out?
One scenario that I can think of is working with a virtual machine (i.e. vagrant w/ virtual box or VMware) on windows host.
You can't translate symlinks to a synchronized folder on Windows share, so you will need this option to go around it.
Use it for any filesystem that doesn’t support symbolic links.
So far one of the scenarios that I came across that --no-bin-links may help is when deploying packages in environments that may not have access to NPM Enterprise and you'd want to actually install all the packages and deploy the node_modules directly, in which case symlinks may cause some problem ( as you can't deploy them ), using this flag solve this problem.
Is there a way to view the documentation of any package I installed in a cabal sandbox? Currently I have a script that places the documentation in a common path so I can view it with a simple server script, but I imagine there's a better or more accepted way of doing this.
To be clear, I do not mean cabal-dev, but the sandboxing tools in the latest cabal.
If you install packages into sandbox with documentation enabled (cabal install --enable-documentation or documentation: True in ./cabal.config), the generated documentation will be put under ./.cabal-sandbox/share/doc/$arch-$os-$compiler/$pkigid. In other words, this works in the same way as with the user package DB (one exception is that a local documentation index is not created in the sandbox case - this is a known issue).