My first time using Composer, mostly because vendor-supplied SDK docs only cover a Composer-based install. I am attempting to get set up to use the QuickBooks Online (QBO) SDK found here: https://github.com/intuit/QuickBooks-V3-PHP-SDK
I have done this:
Steves-Mac-Mini:~ steve$ composer require quickbooks/v3-php-sdk
Using version ^3.4 for quickbooks/v3-php-sdk
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
- Installing quickbooks/v3-php-sdk (V3.4.0): Loading from cache
Writing lock file
Generating autoload files
Steves-Mac-Mini:~ steve$
This left me with:
- composer.lock
- composer.json
- vendor
- autoload.php
- composer
- autoload_*.php files
- installed.json
- quickbooks
- v3-php-sdk
- more composer.json, composer.lock, and other various files
- src
- Directories for each "Class" name
- test
I'm a little confused on what to actually upload to the site at a minimum to make this work. I want to eliminate all the "examples", documentation, and folders that shouldn't be "public" (I read a lot about not uploading the "vendor" directory, but that seemed to apply to git users).
I am not using Git or any version control system on the site. Just FTP. I think this is where my confusion comes from after reading similar questions on SO and the web.
What all do I need to upload, and what files should not be renamed or moved?
Related
i got a problem with composer
In the VM instance, php and some packages installed(listed in composer.lock file)
When i try to install new package at local(i copy package folder from another VM can install via internet) the old composer.lock which list installed package will be replace with information of only new package i install.
step:
i update composer.json with new package
{
"repositories": [
{
"packagist": false
},
{
"type": "path",
"url": "/path/to/artifact/"
}
],
"require": {
"firebase/php-jwt": "^6.4"
}
}
then run
php composer.phar update
new package installed but composer.lock just have only new package(php-jwt) all other contents deleted
Loading composer repositories with package information
Updating dependencies
Lock file operations: 1 install, 0 updates, 50 removals
- Removing cakephp/debug_kit (2.2.9)
- Removing clue/stream-filter (v1.6.0)
- Removing composer/installers (v1.12.0)
- Removing doctrine/instantiator (1.4.1)
...
- Locking firebase/php-jwt (6.4.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
- Downloading firebase/php-jwt (6.4.0)
- Installing firebase/php-jwt (6.4.0): Extracting archive
1 package suggestions were added by new dependencies, use `composer suggest` to see details.
Generating autoload files
No security vulnerability advisories found
what i can do for install new package and update(append) information to composer.lock instead of add only new package to it?
Update: i change update command to require, the same result
php composer.phar require /path/to/artifact/
The command
composer update
reads the composer.json file and update/downgrade/remove/add the packages following the list in the require section to the latest version possible following its rules and avoiding conflicts.
In your case only the firebase/php-jwt is specified, so only itself and its dependecies are kept/updated and all other packages are removed and composer.lock reflects the state after the update operation.
To solve the issue you should use the full package list contained in the composer.json file that references the packages originally installed and add the firebase/php-jwt package manually to it and run the command:
composer update
or use the command:
composer require firebase/php-jwt:^6.4
to let composer add the firebase/php-jwt package to the composer.json file and install the package.
You're effectively updating the lock-file as configured and with the right command - composer update - the question is merely getting the grasp on the removals:
Lock file operations: 1 install, 0 updates, 50 removals
- Removing cakephp/debug_kit (2.2.9)
- Removing clue/stream-filter (v1.6.0)
- Removing composer/installers (v1.12.0)
- Removing doctrine/instantiator (1.4.1)
...
- Locking firebase/php-jwt (6.4.0)
Writing lock file
As composers' version locking shows every package other than firebase/php-jwt must not be installed and is/will be removed, it shows that you have a mismatch between your expectation and what you actually configured composer to do. See the --dry-run option to verify your changes before applying them to validate your expectations beforehand then you can spare yourself the trouble.
Now I wrote that this is "as configured". That is because you shared your configuration:
{
"repositories": [
{
"packagist": false
},
{
"type": "path",
"url": "/path/to/artifact/"
}
],
"require": {
"firebase/php-jwt": "^6.4"
}
}
The only package that is required is firebase/php-jwt. Where have all the others gone? Well, you haven't shared in your question so I can only guess and I'd say you edited the composer.json file and while doing so, you have removed the actual requirements of the project.
Restore the original composer.json and composer.lock files as well as the vendor folder from backup to recover the project requirements and dependencies.
And don't just blindly apply changes to those files. If you're offline just copy the two composer files and the according vendor folder and you're set.
If you can't live being offline and not able to run most of the composer commands for some reason, read the following:
COMPOSER_DISABLE_NETWORK
If set to 1, disables network access (best effort). This can be used for debugging or to run Composer on a plane or a starship with poor connectivity.
If set to prime, GitHub VCS repositories will prime the cache, so it can then be used fully offline with 1. (ref)
And additionally from my own offline experience, you don't have to disable the (default) packagist repository as composer realizes when there is no network and falls back to the cache.
Copy over the (primed) composer cache from the online machine where you get the updates from, it is pretty portable. Study the composer manual if you need dedicated tweaking like overriding the default size limit.
Ok, so I am trying to learn composer. I installed composer using my server's SSH and ran this line:
php composer.phar require tomwalder/php-gds
And it did this:
Using version ^2.1 for tomwalder/php-gds
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
- Installing tomwalder/php-gds (v2.1.0)
Downloading: 100%
tomwalder/php-gds suggests installing google/apiclient (Allows you to use the JSON API Gateway/Datastore endpoints.
Tested with 1.1.6)
Writing lock file
Generating autoload files
Great, so now I look on my webserver and nothing seems to have changed. No files appear to be there. Where does composer install the files to?
Everything is a file called vendor in your current directory. Take a look at Composer documentation to get what you're looking for
The core point: a vendor directory is created in your webroot, with all the packages, but most importantly an autoload.php file. Include it from your main file with require 'vendor/autoload.php'; and magically all classes are available now with the autoloaders.
The cool thing is that you can add an autoload section to your composer.json for your own project, and it will work identically.
I'm having an issue with composer.
I'm working with git in a local environment. I'm the only one developer.
When I need some more dependencies (or need to change some versions), I edit the composer.json and run composer install locally.
Everything's fine.
Then, when everything works locally, I commit my changes (including composer.json and composer.lock) and push to my production server.
A post-receive script updates the sources and runs a composer install on the remote server.
What is expected :
Composer should install the new dependencies according to the composer.lock file.
I should be happy.
What happens :
Composer is angry :
Warning: The lock file is not up to date with the latest changes in
composer.json. You may be getting outdated dependencies. Run update to
update them.
Composer removes all dependencies.
My production is broken.
I have a heart attack
I have to log in to my server via ssh and run a composer update to make things work fine, but I know that a composer update is not recommended on a production server.
Here's the output of the post-receive composer's section :
composer install
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them.
- Removing guzzle/guzzle (v3.9.3)
- Removing symfony/event-dispatcher (v2.7.1)
- Removing geoip/geoip (v1.15)
- Removing pimple/pimple (v3.0.0)
- Removing cocur/slugify (1.1.x-dev)
- Removing bentools/url (0.2)
- Removing bentools/simplexmlextended (1.2.0)
Generating autoload files
What am I doing wrong ?
Thanks,
Ben
This warning
Warning: The lock file is not up to date with the latest changes in composer.json, you may be getting outdated dependencies, run update to update them.
occurs when the md5sum of your composer.json differs from the one stored in the composer.lock:
{
"hash": "b15ed9405e8547867f74973ce8add172",
"packages": [ ... ]
}
Make sure your composer.json and composer.lock are identically with your local ones (compare their md5sums). I suspect that something in your deploy chain is not updating them correctly.
Make sure you added your dependencies locally with the require command:
composer require new/package ~2.5
or if composer.json was edited manually at least run
composer update new/package
after that for every additionally added package to ensure that it is added to your composer.lock properly.
Another approach:
run composer update --lock in production. This will update the hash in your lock file but won't upgrade your vendors.
Then run composer install to install the vendors from your comoser.lock.
When I need some more dependencies (or need to change some versions), I edit the composer.json and run composer install locally.
That's wrong. You can edit composer.json and then must run composer update, or you let Composer do the internal editing of the json file and just run composer require new/package (optionally with a version).
Either way, you should end up with a changed composer.json and composer.lock file, commit BOTH into your repository, and the expected outcome is that the lock file will contain all packages in the correct versions, which should be installed in production with a regular composer install run.
Note that your workflow is still very dangerous. If you push, and Github is down - how would you get the ZIPs to install?
I'd like to know whats the difference when creating new symfony project with new symfony installer that has appeared last time and old-way composer.
I've installed latest version of symfony (2.6.1) with both, and result was different, for example when I install symfony with composer, i get .gitignore file.
When I install with new symfony installer script, gitignore is missing.
Here is amount of catalogs and files in fresh project:
symfony installer: 1498 directories, 7136 files
symfony installer + composer update: 1571 directories, 7749 files
composer create-project: 1615 directories, 7905 files
I suppose I'll stick to old way - composer, since new installer seems to be bugged or at least not complete yet, however I'd like to understand more on this topic, whats the difference, is it safe to use new installer etc?
As Leggendario already explained, the installer downloads the dist files from the website (a .tar.gz or .zip file). This speeds up the installation process quite a bit.
However, when building the dist files, symfony.com uses a custom build script which removes some files and changes some things. On the other hand, composer simply downloads the repository for you.
The main differences:
Composer downloads the latest dependencies (as Leggendario pointed out), while the build script contains the latest files at the moment of building.
Composer uses the dev versions and thus uses git clone to download the packages. The build script uses only stable packages, which will make Composer use the dist version. Some packages remove test and doc files from their dist files.
Composer contains all project related information, like a .gitignore. The build script previously assumed the person installing it didn't have git, so removed this file and other git related files like the .gitkeep files in app/cache and app/logs.
I any case, both the installer and composer always give you a working version of the Symfony Standard Edition.
At last, the build script was changed now the installer became the official way of installing. It'll now contain the git related files. On the other hand, it'll not contain the LICENSE file, UPGRADE-*.md files and README.md file. So in the end, we can say that the one installed by the installer is more usable, as it removes useless files.
Symfony2 Installer will downloaded it from the web site ( in this case: http://symfony.com/download?v=Symfony_Standard_Vendors_2.6.1.zip ).
To see the differences between symfony installer and the classic composer create-project is enough to take a look at both composer.lock: https://www.diffchecker.com/oig86oki
On the left the composer.lock generated after composer create-project, on the right symfony installer. It was obvious to everyone that Symfony2 downloaded from an archive could not have the lastest packages. So, do the update with composer update.
Again, on the left the composer.lock of composer create-project, on the right the new composer.lock after the update: https://www.diffchecker.com/lj5j2eap
As we expected. But in the vendor dir there are not the same number of file. Some folders are not there. Some folders with functional tests are not downloaded with symfony installer. You need to force composer to update all packages, or reinstall them.
Did you update installer as well with :
symfony self-update
or in windows :
php symfony.phar self-update
As stated here ?
That's perhaps one part of the answer.
Among differences, the installer seems to deal better with different symfony versions.
I recently downloaded a version of Laravel 4 and it was only 40kb. Laravel 3.2 was about 3.5mb, my questions are:
How can I use Laravel 4 completely offline?
I found out, Laravel 4 core codes was missing, Does it work cloud base or something like it!?
Which version do you recommend to use? Laravel 3.2 or Laravel 4? ( mostly for local developing )
thanks.
How did you installed Laravel? Using composer is as simple as:
composer create-project laravel/laravel your-project-name --prefer-dist
I use Laravel 4 for local development, and it works like a charm!
That's mainly because Laravel 4 uses composer to handle dependencies. What you downloaded wasn't exactly Laravel, but rather the structure for it. It's a preset project, with all default Laravel dependencies, so that all you have to do is run a command and download it all.
To use Laravel 4, you'll need to install composer. After you're done, open your command line, go to the folder where you saved the Laravel files you downloaded and, inside it, type: php composer install. This will download all the dependencies needed for the project; that means Laravel files and all of its own dependencies. It may take a while to install, and may seem to be stuck at Installing dependencies (including require-dev) for quite a long time, since there are lots of dependencies to be fetched, but that's normal. After it's done, you should see something like this:
Loading composer repositories with package information
Installing dependencies (including require-dev)
- Installing doctrine/lexer (dev-master bc0e1f0)
Downloading: 100%
...
- Installing laravel/framework (4.0.x-dev 733492c)
Downloading: 100%
...
Writing lock file
Generating autoload files
Generating optimized class loader
Now all you have to do is point the root of your webserver to the /public folder and start programming. If you ever feel you want to update your dependencies, simply run composer update.
Note: Remember to enable PHP's openssl extension, so composer can download the projects from github, and Apache's mod_rewrite, so Laravel pretty URLs work. If you're using Apache, that is.
Note²: Whenever you create a new command, controller, model, migration or seed, you'll have to type composer dump-autoload on your console, so composer knows how to autoload it.