I started working in a huge project written in Symfony which is at version 2.8. Upgrading the whole project to SF 3 would take hundreds of hours and it's not possible right now. I came up with an idea to unpack symfony/symfony package to single packages it replaces (key replace in composer.json). It would unlock all 45 packages that are locked on self.version and allow us to upgrade any package step by step if possible.
Example: I have doctrine/orm locked at 2.5.* and cannot ugrade to 2.6 (what will get rid of few bugs and also allow me to upgrade PHP 7.2 --> 7.3) because I have symfony/console locked by symfony/symfony at version 2.8 and doctrine/orm:2.6 requires symfony/console:~3.0.0. However my project would allow to have symfony/console even at version ^3.2 so you can see my point.
I would like to ask you if there are any dangers to the application when attempting to unpack symfony/symfony? So far I can't see any.
P.S. Info for those how want to answer "just require a single package with higher version". Since Composer 1.7.3 it's not possible and will trigger a version conflict.
In such case it will be better to walk in a tiny steps and carefully check results of each step. Of course if whole your project is covered by tests it would be much simpler to do such change, but I don't know if it is.
I would probably do something like this:
Copy composer.json into separate directory
Get exact versions of packages by running composer info
Look into list of packages provided by symfony/symfony e.g. by looking into its own composer.json or by looking at its page on Packagist.
Replace symfony/symfony in copied composer.json with individual packages of same versions as you currently have.
Run composer install and compare resulted set of actually installed packages with packages installed for your project. Simplest way is to compare output of composer info from both directories. You can also use something like composer info | awk -F ' ' '{print $1 " " $2}' | sort to get sorted list of packages and their versions so it will be easier to compare.
Tune packages list and version constraints until you will achieve same results from composer info for both actual project and your new composer.json.
Copy composer.json back into main project. By this time you will be able to install same vendor packages but will be able to control them separately.
Go on with package versions tuning but don't forget to apply minimal changes at a time and test (hopefully by running auto-tests) each change separately.
I hope you know composer why command that allows you to examine package dependencies so you will understand better which packages will get affected by changing version of some particular package.
Good luck with this task because careful upgrade may take quite some time.
Related
I have a fresh Drupal 10 Installation und would like to install some modules with more ore less simple patches. I tried it in different ways and get allways the same errors with composer require.
This are my steps:
manual changed files for exampe in superfish for this patch:
https://www.drupal.org/files/issues/2022-08-01/superfish-%233.patch and manually put the module in module/contrib folder. Than I tried composer require drupal/superfish:~1.4 with different versions and with and without parameter -W.
I wrote patch in composer.json and tried composer install. There comes the message nothing to install or update. I used also composer update --lock
I downloaded last dev-Version and patch and tried with git apply.
The result with composer require is more ore less the same error like this:
Problem 1 - drupal/block_content_permissions[1.0.0, ..., 1.8.0]
require drupal/core ^8 -> found drupal/core[8.0.0, ..., 8.9.20] but
these were not loaded, likely because it conflicts with another
require. - drupal/block_content_permissions[1.9.0, ..., 1.10.0]
require drupal/core ^8 || ^9 -> found drupal/core[8.0.0, ..., 8.9.20,
9.0.0, ..., 9.5.0] but these were not loaded, likely because it conflicts with another require. - Root composer.json requires
drupal/block_content_permissions * -> satisfiable by
drupal/block_content_permissions[1.0.0, ..., 1.10.0].
You can also try re-running composer require with an explicit version
constraint, e.g. "composer require drupal/block_content_permissions:*"
to figure out if any version is installable, or "composer require
drupal/block_content_permissions:^2.1" if you know which you need.
If I enable the patched modules manualy in backend, they work normaly. But they are not under composer controll.
How to do in the right way?
Drupal.org has a documented process for allowing a lenient composer install.
For Drupal 10:
Try the Lenient Composer Plugin
The lenient composer plugin lets you specify an allowlist of packages
where you are willing to break the version constraint, using a command
like:
composer config --merge --json extra.drupal-lenient.allowed-list '["drupal/token"]'
Together with the Composer Patches Plugin, this allows you to install
any Drupal extension, even if the version constraint hasn't been
officially updated yet. Of course the code may still need to be
patched for deprecations.
First of all, I can't use composer because Im under a corporate network. I tried everything to get composer working :
HTTP_PROXY, HTTPS_PROXY, HTTPS_FULLURI ... Nothing is working. Composer diag gives an OK status for http packagist but FAILS for https connectivity. The error it gives me is:
SSL : Handshake timed out.
But that's not my question, I spent to much time trying to get composer working (But if you got a solution, you'll make my day )
My real question is the following : How to install bundles manually
I want to install this bundle : http://knpbundles.com/pierredup/MenuBundle.
What I did to try installing the bundle :
Registering the bundle in appKernel.php :
new \CS\MenuBundle\CSMenuBundle()
Tried to add it in the autoload.php :
$loader->add('CS', __ DIR __.'/../vendor/CS/CSMenuBundle.php');
(Dont know how to add php code properly ... )
But it doesn't work, got the following error :
Attempted to load class "CSMenuBundle" from namespace "CS\MenuBundle".
Did you forget a "use" statement for another namespace?
And then, even if it is not a good practise, I tried to add it to autoload_namespaces.php and did a dump-autoload after that :
'CS\MenuBundle' => array($vendorDir. '/CS/')
I still have an error, but not exactly the same one :
Attempted to load class "CSMenuBundle" from namespace "CS\MenuBundle".
Did you forget a "use" statement for "CS\MenuBundle\CSMenuBundle"?
Now I'm a bit frustrating, I saw many posts (not on Stack) where people scream because we have to use composer to manage dependencies. I totally agree with that, but I can't, so I'm trying to find another way, and as I can't find any clear tutorial which explains how to install vendors without composer, here I am.
Note that I commented on the problems I see with your approach on your question directly.
However, I looked at the package you want to use to see if there would be ANY chance installing it somehow (preferring Composer). I don't think it is possible or feasible.
composer require customscripts/menubundle:dev-master - this would be the easy command for Composer to do everything. However there are problems:
The package you want to use is not registered on packagist.org, so there is no way to simply use Composer on a machine properly connected to the internet, grab the packages, zip them and transfer them to the place you need it.
To work around this, you'd manually add the repository to the composer.json file - this might actually work (however it takes way too much time on my VM). You'll end up with code that was last edited in the year 2012!
The dependencies of that code will likely not work anymore. The composer.json of that package lists "require": {"knplabs/knp-menu-bundle": "dev-master", "symfony/framework-bundle": ">=2.0,<2.3-dev", "jms/di-extra-bundle": "1.1.*"} - even the first "knplabs/knp-menu-bundle" will never work. Remember that the code of this package is from 2012 - now we are in 2016, so "knp-menu-bundle" has seen four years of development on the master branch. There simply is NO WAY of knowing which commit had been used of this package. You'd have to reverse-engineer this lost information.
Additionally, you see why Composer is awesome and doing it manually is bad: In addition to your wished package, you have to download the three additional packages mentioned here.
But detecting packages that have to be added is a recursive task: knp-menu-bundle has a dependency on knp-menu (with no further dependencies) and symfony/framework-bundle (already added). symfony/framework-bundle itself has a dependency on 9 more Symfony packages and doctrine/common... and so on. You have to detect every single package of this and download the correct version manually if you cannot use Composer.
Skipping your original package because that installation wasn't finishing while I was typing my answer, I tried to install knp-menu-bundle to see how many packages would be installed. Composer installed 20 packages, some of them using Symfony in 2.8 (it SHOULD be compatible with Symfony 2.2 stuff, shouldn't it) - and I simply ran composer require knplabs/knp-menu-bundle:1.1.1 to grab a similarly old version of knp-menu-bundle from 2012.
The strength of using Composer is that it supports rapid development by allowing updating quickly, downgrading reliably (if you commit your composer.lock file and always use tagged versions), and simply allowing to add new packages instantly. Not being able to use Composer is a very severe limitation for you as a PHP developer. Talk to your boss or team lead about your company's situation with the HTTPS proxy, and find a solution to use Composer. The alternative is to develop everything from scratch on your own or waste plenty of hours trying to fiddle with manual downloads that don't fit together easily.
In pre-buildout-times one would install ZOPE2 by downloading the tarball of http://old.zope.org/Products/Zope/ and do the configure/make/install-procedure.
Since ZOPE version 2.12 releases are made on pypi. Would it still be possible to install newer ZOPE2-versions the same way manually without using buildout?
Perspectively Plone is ment to be put on top ZOPE2, but to narrow down the question for now, an answer only concerning ZOPE2 is very welcome.
I may be late to the party but:
As a starting point: There is the projects installation docs at https://zope.readthedocs.io/en/2.13/INSTALL-virtualenv.html which worked fine (and is without buildout) the last time I tried.
Since I use virtualenv and pip a lot, the above method becomes cumbersome fast (installation from different path than pypi and local equivalent, accidentally upgrading wrong packages when installing more packages) I made an almost pure reference installation and then just did a pip freeze > zope_2.13_requirements.txt.
Now I can just create a new virtualenv and do a quick pip install -r zope_2.13_requirements.txt, can do it directly via pipy and have a fresh installation whenever I need.
The main part of the question probably is that you probably want to use Zope 3 and not legacy Zope 2 (which e.g. Plone still depends on). Zope is not a signle, coherent, entity. What components of Zope stack you want to use (zope.interface, zope.component, ZODB, Medusa web server, Zope management interface, others?) All are individual Python packages and can be used as is in any Python application with normal Python package workflow.
Buildout is nothing but scripts, templates and Python package installer with advanced dependency solving.
You can still install all Zope packages by hand, resulting a lenghty requirements.txt. Zope 2 comes with command line scripts for creating and maintaining databases and you can call these scripts by hand, no need to go through buildout. You can also create configuration files by hand, e.g. looking the examples generated by buildout if you have some specific legacy project in mind.
For example, substanced, a CMS based on Pyramid and ZODB, does not rely on buildout. Pyramid internally uses zope.interface, zope.component and various other packakages.
How do I find out what is holding my app up from updating? I keep getting the 'This project is at the latest release which is compatible with your current package constraints.' message.
Here is the output from the update command:
Refreshing package metadata. This may take a moment.
Figuring out the best package versions to use. This may take a moment.
Figuring out the best package versions to use. This may take a moment.
Figuring out the best package versions to use. This may take a moment.
This project is at the latest release which is compatible with your
current package constraints.
My packages.js looks like so:
# Meteor packages used by this project, one per line.
#
# 'meteor add' and 'meteor remove' will edit this file for you,
# but you can also edit it by hand.
accounts-base
accounts-password
alanning:roles#=1.2.9
arunoda:npm#0.2.6
ch-activity
ch-activityreport
ch-arrestreport
ch-assetreport
ch-citation
ch-fieldinterviewreport
ch-incidentreport
ch-inspectionreport
ch-location
ch-media
ch-narrative
ch-organization
ch-person
ch-property
ch-signature
ch-vehicle
cmather:iron-router#0.8.2
coffeescript
copleykj:mesosphere#0.1.9
d3
dash-patrol
email
less
mizzao:bootboxjs#4.2.1-master.1
mrt:accounts-ui-bootstrap-3#=0.3.3
mrt:leaflet#0.3.8
mrt:mongo-counter#1.1.0
notices
sacha:spin#2.0.4
standard-app-packages
tsega:bootstrap3-datetimepicker#=0.2.0
I have migrated all the ch-* and dash-* packages to the new format. Those are local, in app, packages. Those cannot be in public repositories.
Try replacing
cmather:iron-router#0.8.2
with
iron:router#0.9.1
in your packages file.
I'm think it may be because not all your packages are compatible with Meteor 0.9.0
If you want to check what packages are currently compatible enter this code:
meteor search (Package Name)
By default meteor will only return compatible packages, so you can find which packages aren't working by searching each one. If you can't find the package, then its probably not compatible and you aren't going to be able to run the latest version of Meteor unless you remove it.
Don't worry though! While Meteor 0.9.0 is quite buggy, they are working hard to update all the packages and patch the bugs. Just give it a few weeks to sort itself out if that doesn't work :)
Best Of Luck! Hope This Helped!
Meteor search is included in the latest release. Docs: http://docs.meteor.com/#meteorsearch
Try running this command and you should be able to access meteor search
meteor update
Also, the update should tell you if there's a package update available, although I had to run update (packagename) on each starred package for it to update
meteor update aldeed:collection2
I found that I had to remove my ~/.npm directory and run meteor again to resolve some npm dependencies I had. Perhaps you have some npm dependencies as well?
I need to install only 1 package for my SF2 distribution (DoctrineFixtures).
When I run
php composer.phar update
I get
- Updating twig/twig (dev-master 39d94fa => v1.13.0)
The package has modified files:
M CHANGELOG
M doc/filters/batch.test
M doc/filters/index.rst
M doc/filters/url_encode.rst
M doc/functions/index.rst
M doc/tags/index.rst
M doc/tests/index.rst
M lib/Twig/Autoloader.php
M lib/Twig/Compiler.php
M lib/Twig/CompilerInterface.php
-10 more files modified, choose "v" to view the full list
It appears the last developer edited a lot of files inside vendor.
In order to get around this, I tried
php composer.phar update <package_name>
But that doesn't seem to work. How can I update/install only one library from composer.json?
To install doctrine/doctrine-fixtures-bundle with version 2.1.* and minimum stability #dev use this:
composer require doctrine/doctrine-fixtures-bundle:2.1.*#dev
then to update only this single package:
composer update doctrine/doctrine-fixtures-bundle
If you just want to update a few packages and not all, you can list them as such:
php composer.phar update vendor/package:2.* vendor/package2:dev-master
You can also use wildcards to update a bunch of packages at once:
php composer.phar update vendor/*
As commented by #ZeroThe2nd ZSH users may need to wrap their vendor/* in quotation marks:
php composer.phar update "vendor/*"
--prefer-source: Install packages from source when available.
--prefer-dist: Install packages from dist when available.
--ignore-platform-reqs: ignore php, hhvm, lib-* and ext-* requirements and force the installation even if the local machine does not fulfill these. See also the platform config option.
--dry-run: Simulate the command without actually doing anything.
--dev: Install packages listed in require-dev (this is the default behavior).
--no-dev: Skip installing packages listed in require-dev. The autoloader generation skips the autoload-dev rules.
--no-autoloader: Skips autoloader generation.
--no-scripts: Skips execution of scripts defined in composer.json.
--no-plugins: Disables plugins.
--no-progress: Removes the progress display that can mess with some terminals or scripts which don't handle backspace characters.
--optimize-autoloader (-o): Convert PSR-0/4 autoloading to classmap to get a faster autoloader. This is recommended especially for production, but can take a bit of time to run so it is currently not done by default.
--lock: Only updates the lock file hash to suppress warning about the lock file being out of date.
--with-dependencies: Add also all dependencies of whitelisted packages to the whitelist.
--prefer-stable: Prefer stable versions of dependencies.
--prefer-lowest: Prefer lowest versions of dependencies. Useful for testing minimal versions of requirements, generally used with --prefer-stable.
Difference between install, update and require
Assume the following scenario:
composer.json
"parsecsv/php-parsecsv": "0.*"
composer.lock file
"name": "parsecsv/php-parsecsv",
"version": "0.1.4",
Latest release is 1.1.0. The latest 0.* release is 0.3.2
install: composer install parsecsv/php-parsecsv
This will install version 0.1.4 as specified in the lock file
update: composer update parsecsv/php-parsecsv
This will update the package to 0.3.2. The highest version with respect to your composer.json. The entry in composer.lock will be updated.
require: composer require parsecsv/php-parsecsv
This will update or install the newest version 1.1.0. Your composer.lock file and composer.json file will be updated as well.
You can use the following command to update any module with its dependencies
composer update vendor-name/module-name --with-dependencies
You can basically do following one to install new package as well.
php composer.phar require
then terminal will ask you to enter the name of the package for searching.
$ Search for a package []: //Your package name here
Then terminal will ask the version of the package (If you would like to have the latest version just leave it blank)
$ Enter the version constraint to require (or leave blank to use the latest version) []: //your version number here
Then you just press the return key. Terminal will ask for another package, if you dont want to install another one just press the return key and you will be done.
Just use
composer require {package/packagename}
like
composer require phpmailer/phpmailer
if the package is not in the vendor folder.. composer installs it and if the package exists, composer update package to the latest version.
Update:
require install or update the latest package version. if you want update one package just use update.
To ensure that composer update one package already installed to the last version within the version constraints you've set in composer.json remove the package from vendor and then execute :
php composer.phar update vendor/package
Because you wanted to install specific package
"I need to install only 1 package for my SF2 distribution (DoctrineFixtures)."
php composer.phar require package/package-name:package-version
would be enough