guys!
I simply want to clone repository via composer. But unfortunately - i can't.
My composer.json looks like:
{
"repositories": [
{
"type": "vcs",
"url": "https://bitbucket.org/yuriikrevnyi/bitrix-teil-framework"
}
],
"require": {
"mockery/mockery": "dev-master#dev",
"phpunit/phpunit": "3.7.*"
}
}
But its not going to work.
So, couldnt you help me a little bit?
And there is one more question. How to 'clone' private repo with composer? Lets say, we have same repo - https://bitbucket.org/yuriikrevnyi/bitrix-teil-framework. And admin password is - PASSWORD
So, how the composer.json should look now?
Thanks!
The respositories section is only to define packages that are not present in the packagist.org database, but it is present on a 'source control'.
So, it is like you tell composer in your composer.json that there is a package which is source controlled, and here are the details where you get it from, by defining url .. etc.
But that is not enough, because that is only definition and not consuming (downloading) the package. In order to do so, you need to add it to your require section as well.
{
"repositories": [
{
"type": "vcs",
"url": "https://bitbucket.org/yuriikrevnyi/bitrix-teil-framework"
}
],
"require": {
"mockery/mockery": "dev-master#dev",
"phpunit/phpunit": "3.7.*",
"yuriikrevnyi/bitrix-teil-framework": "*"
}
}
In your posted composer.json you are stating multiple facts.
You state that the software this composer.json belongs to requires the packages named "mockery/mockery" and "phpunit/phpunit".
You also state that there is some repository existing that might contain some software.
What you are not stating is that Composer should clone that repository - and you cannot do this with Composer. Composer will by default only know about packages registered at packagist.org, and additionally will look into any declared repository to see which software is in there in case that software is required.
So without having another composer.json in that repository hosted at Bitbucket, nothing will happen. Also, without requiring the software that is hosted there, nothing will happen.
Your problem description is missing the most important parts to help ypu better:
Describe what you were doing.
Describe the expected result.
Describe the actual result and how it differs from the expected result.
What you are describing is roughly point 1 (could have more details), your words "it does not work" fails to describe point 3, and point 2 is missing alltogether.
Related
Since our project needs a library to run tests, this package is listed in the require-dev section of composer.json.
{
//...
"require": {
"php": "^7.4|^8.0",
},
"require-dev": {
"cache/array-adapter": "^1.1"
},
//...
}
During a manual code review, I realised that this library is being used in our production code too.
The fix is easy, we moved the corresponding package from the require-dev section to the require section.
{
//...
"require": {
"php": "^7.4|^8.0",
"cache/array-adapter": "^1.1"
},
"require-dev": {
},
//...
}
I'm searching an automatic way/test to avoid this kind of problem. I guess that our manual test during staging can avoid these kind of problem, but it isn't enough.
How to check that a dev-dependency isn't needed in our core-code?
You could implement this using PHPStan (or Psalm, or any other static analyzer): if you removed the dev dependencies and then run such a tool, it would notify you about missing classes from such a dependency.
But be warned: even if this helps to write more strict code, it might need some work in the beginning to implement proper return types all over your application
Another idea: also remove dev dependencies and run a usual test suite like PHPUnit or Behat.
I guess you could do it with deptrac. Although it's generally used to track internal architectural dependencies, nothing stops you from configuring it to track external dependencies.
It would require you manually configuring the "dev" layer with different "collectors", one for each dev dependency namespace, and a base layer for your App namespace.
Anything in App that depends on the dev layer would be a violation, unless explicitly allowed. You could even put this in CI (which is a common use-case of deptrac), where any violation would stop the deployment.
The configuration would be something like this (untested):
paths:
- ./src/
exclude_files: ~
layers:
- name: App
collectors:
- type: className
regex: App\\.*
- name: Dependencies
collectors:
- type: className
regex: Symfony\\Bundle\\MakerBundle\\.*
- type: className
regex: Cache\\Adapter\\PHPArray\\.*
I have a project, and I need some packages, so I reorganized the project to use PSR-4.
Here's my composer.json:
{
"name": "me/production",
"type": "project",
"authors": [
{
"name": "Me",
"email": "me#me.com"
}
],
"config": {
"platform": {
"php": "5.6.1"
}
},
"autoload": {
"psr-4": {
"API\\": "api/"
}
},
"require": {
"nesbot/carbon": "^2.25"
},
}
it doesn't work in my scripts. But, here's the real kicker: I do require_once __DIR__ . '/vendor/autoload.php'; in my php console, and it doesn't work either. I have triple and quadruple checked the path, the autoload is there.
What do I mean by "doesn't work"? the autoload requires successfully. It allows me to use libraries. BUT actual instantiations result in a
Class not found error.
Not only for my classes in the API namespace, which are namespaced in the top of the file and are exactly in the folder they're suppose to be, but I also CANNOT instantiate Carbon. I can use Carbon\Carbon but any attempt to instantiate will fail.
Interestingly, instantiation of \Carbon\Carbon directly does not fail.
What's going on? This is weird.
Thank you in advance.
EDIT: I tried redumping the autoloader, I also tried removing the vendor folder and reinstalling. All to no avail.
EDIT: May be worth mentioning I downgraded carbon to ^1.21 because carbon 2 doesnt support php 5.6. But it still doesn't work.
EDIT: It happens with my API namespace as well, here's an example using my implementation of the Instagram API:
use \API\Insta;
php > var_dump(new Insta);
PHP Fatal error: Class 'Insta' not found in php shell code on line 1
php > var_dump(new \API\Insta);
object(API\Insta)#3 (1) {
["ig_token"]=>
string(51) "A_VALID_TOKEN"
}
php >
EDIT: The problem solved itself, it has now mutated into one I care very little about: I can use everything but not in the php console. I am not sure what fixed it.
As you found out, nesbot/carbon, version 2.25 requires at least PHP v7.1.8.
Just having a use statement doesn't check anything, instead it creates a local alias that can be used. If you try to use something that does not exist, only then would it fail.
Please clarify that you have the following directory structure:
./composer.json
./composer.lock
./Api/Insta.php
and in the file Api/Insta.php:
namespace API; // this is your top namespace name
use Carbon/Carbon; // etc
class Insta { ... }
Having the namespace different to the directory name can lead to confusion.
There will also be the index.php/front-controller that pulls in the vendor/autoload.php file and presumably runs the framework.
We added PHPExcel to composer by adding the following
To repositories:
{
"type": "package",
"package": {
"name": "PHPOffice/PHPExcel",
"version": "1.9",
"source": {
"url": "https://github.com/PHPOffice/PHPExcel.git",
"type": "git",
"reference": "1.9"
},
"autoload": {
"psr-0": {
"PHPExcel": "src/"
}
}
}
To require:
"PHPOffice/PHPExcel": "1.9.*"
In our code:
use PHPExcel\IOFactory;
...
$file = $request->get('file');
$inputFileType = IOFactory::identify($file);
The error we get is:
Attempted to load class "IOFactory" from namespace "PHPExcel".
Did you forget a "use" statement for another namespace?
The namespace looks right (https://github.com/PHPOffice/PHPExcel/blob/1.9/src/PhpSpreadsheet/IOFactory.php).
Use of the 1.9 branch is not recommended. It isn't completely converted yet to use namespaces, and is subject to significant code change. Nor is it backward compatible with the official 1.8 branch, and the changes are not yet documented, and also subject to further major changes as we modify the code to take advantage of the newer features of PHP.
The official release branch is still 1.8
Just because the 1.8 branch exists on github, doesn't mean that it's working code. I store it there so that it's available for shared development, and as a security (rather than keeping it all on my development laptop) in case I get run over by a bus tomorrow.
I have not used 1.9. Glad to see that they are moving to namespaces. That said, you might be better off sticking with 1.8 just for stability.
In any event, 1.9 relies on psr-4. Try adding this to your composer.json file:
"autoload": {
"psr-4": {
"PHPExcel\\": "src/PhpSpreadsheet"
}
}
Then rebuilding the composer generated autoload.php file.
I have an ecommerce site that i am building for a client. This site had previously worked perfectly fine using procedural functions and curl to make the calls to Paypal. I download the Mailgun and Easypost API manual and installed manually. DOwn the road, I wanted to update the site to utilize PDO & OOP. I have done a fair job at getting the foundation laid. Now it is time to start making calls to the various API's.I installed everything using composer and currently run a dual autoloader. The composer autoload and then beneath it a custom autoload to load my classes. Now, when I call on the PayPal API, I get the following error:
Fatal error: Class 'Paypal\Rest\ApiContext' not found in /var/www/html/myla-dev/shoppingCartFinalize.php on line 18
I think what is happening is my autoloader is trying to load this rather than the composers autoloader. Here is where the autoloading is occurring:
init.php
require __DIR__.'/core/functions/general.php';
function autoLoader ($class) {
if (file_exists(__DIR__.'/core/classes/'.$class.'.php')) {
require __DIR__.'/core/classes/'.$class.'.php';
}
}
spl_autoload_register('autoLoader');
require __DIR__.'/vendor/autoload.php';
This file sits in project root directory and is then required at the top of every file.
File Structure
core
--classes
----Alert.php
----....
--functions
----general.php
vendor
--composer
--easypost
--guzzle
--mailgun
--symfony
--paypal
--autoload.php
index.php
init.php
...
composer.json
{
"repositories": [
{
"type": "vcs",
"url": "https://github.com/EasyPost/easypost-php"
}
],
"require": {
"php": ">=5.3.0",
"easypost/easypost-php": "dev-master",
"ext-curl": "*",
"ext-json": "*",
"paypal/rest-api-sdk-php":"*",
"mailgun/mailgun-php": "dev-master"
}
}
Any and all assistance is appreciated. If you feel like writing code, GREAT, but that is not what I am asking for. That is my job, but help with reworking to make it work would be awesome.
Thanks
It ended up being a simple syntax error. After I dumped and updated composer it still failed to work, so I just copied the code from the installation wiki. It worked so I composer their code to mine and I was missing a backslash in my call to the wiki. Thank you for your assistance though.
How i can add adLDAP library to LARAVEL 4 ?
http://adldap.sourceforge.net/
That library does not offer a composer.json file yet, you you have to create the necessary information yourself.
I have created a sample file that successfully downloaded something that looks good, but I haven't used the code.
{
"require": {
"adldap/adldap": "4.0.4"
},
"repositories" : [
{
"type": "package",
"package": {
"name" : "adldap/adldap",
"version": "4.0.4",
"dist": {
"url": "http://sourceforge.net/projects/adldap/files/adLDAP/adLDAP_4.0.4/adLDAP_4.0.4r2.zip/download",
"type": "zip"
},
"source": {
"url":"https://svn.code.sf.net/p/adldap/code/",
"type": "svn",
"reference": "tags/v4.0.4/"
},
"autoload": {
"classmap": ["src/"]
}
}
}
]
}
You'd have to create one repositories entry per version you are about to use (one entry is enough if you don't plan do something fancy). I created the entry for the most recent version 4.0.4 - if there is an update, you have to change the version tags everywhere.
The require entry should be added to whatever you are already using.
The distribution URL is a rough guess by following the download link to the ZIP file offered on Sourceforge, bypassing any ad-filled download page. It might stop working unexpectedly. If you delete the whole dist section, you will checkout from the original SVN repository instead, which might be slower than downloading and unpacking a ZIP file.
After that, you are all set with the Composer part. The remaining thing is to include Composer autoloading in the Laravel bootstrapping (you might already have that done), and then enjoy the LDAP classes.
Anyone coming across this in the future, adLDAP has a composer file now and can easily be autoloaded.
"require": {
"adldap/adldap": "4.0.*"
},
Then load the library in your controller:
$ldap = new \adLDAP\adLDAP($config);