When I installed omnipay through composer I got the following errors. Are there any plans to use the latest version of Guzzle?
Package guzzle/common is abandoned, you should avoid using it. Use guzzle/guzzle instead.
Package guzzle/stream is abandoned, you should avoid using it. Use guzzle/guzzle instead.
Package guzzle/parser is abandoned, you should avoid using it. Use guzzle/guzzle instead.
Package guzzle/http is abandoned, you should avoid using it. Use guzzle/guzzle instead.
Package guzzle/plugin-mock is abandoned, you should avoid using it. Use guzzle/guzzle instead.
Yes, Omnipay V3 will use Guzzle 5.0, rather than Guzzle 3. It was discussed here: https://github.com/thephpleague/omnipay/issues/235
Related
I keep getting the following error, I'm using meteor 2.1 currently
Error: A new entrypoint in the #emotion/styled package, #emotion/styled/base, has replaced the #emotion/styled-base package. Please remove this package and use #emotion/styled/base instead.
i cannot find ANY way to install this #emotion/styled/base package. #emotion/styled-base is installed and i cannot create a build suddenly.
any suggestions???
I'm using react.js
#emotion/styled/base isn't a package you need to install, but rather its a submodule of the #emotion/styled package.
I have a hunch that you are not using #emotion/styled-base directly, so most likely what you have is a version mismatch where you have a newer version of #emotion/styled installed, but that package is written for an older version. You'll probably just need to locate this offending package and update it.
If this isn't the case, then you'll just need to replace your imports for #emotion/styled-base with ones for #emotion/styled/base
I need to use python3.7m instead of default python3.8 in my buildroot project. Is there a solution for that or only way is get older buildroot version?
You do not have to downgrade Buildroot. You can always add a custom python3 package based on an older version, e.g.: https://git.busybox.net/buildroot/tree/package/python3?id=b3424c8fc9d1199f5836483f15af48b56373609e
Here the documentation on how to add a package:
https://buildroot.org/downloads/manual/manual.html#adding-packages
One possibility is to add a custom package with a different python version, as #Ezra Bühler explained. However, that custom package must have a different name than python3, which means that you also need to make custom versions of all packages that use python3.
Therefore, a simpler possibility is to modify the Buildroot code itself. There's normally no need to go back to an older Buildroot version - instead, you can take just copy and overwrite python3 from an older version that still has python 3.7. Of course, this is a completely untested configuration so you might encounter some breakage, but it's usually doable. If you take that route, you'll want to also update python to the latest (currently python 3.7.11).
Installing PHPUnit with composer globally seems more convenient to me for those two reasons:
1. Using it everywhere without needing an extra install.
2. Just running phpunitinstead of vendor/bin/phpunit (using an alias might solve this)
Are there any reasons why a local install might be the better choice? For example: using the exact same versions every time. (don't have a lot of experience with PHPUnit, so not sure if this really is an issue or not)
The big disadvantage of installing packages globally is that you might end up with different versions of PHPUnit between developers in your team (unless you are the only developer). This might cause some side effects.
If you install it locally using composer.json, then every developer in your team will have exactly the same version as you do for that specific application. Also, everybody will see when you change the version in composer.json.
If you don't like typing vendor/bin/phpunit, you can use Makefile (which is also in your project):
test:
vendor/bin/phpunit --configuration=test/Unit/phpunit.xml
then run it ...
make test
I like to install it via composer and the require-dev block, but another way that does come highly recommended is to download the phpunit.phar into the project, to use that.
Either way, you control exactly which version is being used (and when it's updated) - which is the most important part, as you can't so easily control what people have installed globally.
I'm using maven, but I dont understand the difference between following dependencies:
1.)
http://mvnrepository.com/artifact/org.apache.cxf/cxf-bundle/3.0.0-milestone2
2.)
http://mvnrepository.com/artifact/org.apache.cxf/cxf-bundle-compatible/3.0.3
Option 2 seems newer, but can I use it?
At the moment I use "http://mvnrepository.com/artifact/org.apache.cxf/cxf-bundle/2.7.14", but I want to upgrade to V. 3.x.x
I haven't found any informations about the cxf-bundle/3.0.0-milestone2 yet, but perhaps someone knows, whre to find more informations about this one.
The big monolithic bundle was removed in 3.0. Use the individual bundles that you need for your application.
I don't find anywhere that the version attribute of a merge module is used, not even for upgrading scenarios. What is it used for then?
It's only used during the merge process to validate that the version of the module is compatible with the version the installer is expecting to consume.