I've got the old PHP azure SDK working on a Azure website, but I would like to migrate to the new one. Unfortunately, I'm unable to get the new one to work.
I've installed the SDK manually and followed the "Usage" steps on this page: https://github.com/Azure/azure-sdk-for-php. Instead of 'use' I use 'require', maybe that's where it goes wrong but I don't know how to use namespaces.
The environment I use to edit my code is dreamweaver.
The following code goes wrong at the line starting with $tableRestProxy
<?php
require("WindowsAzure/WindowsAzure.php");
require("WindowsAzure/Common/ServicesBuilder.php");
require("WindowsAzure/Common/ServiceException.php");
require("WindowsAzure/Table/TableRestProxy.php");
$connectionString = 'DefaultEndpointsProtocol=https;AccountName=[AccountName];AccountKey=[AccountKey]';
// I do know that I have to declare the AccountName and AccountKey here. Left it out for privacy reasons.
$tableRestProxy = ServicesBuilder::getInstance()->createTableService($connectionString);
?>
update
Now I'm trying to use Composer to install the SDK. My composer.json file looks like this:
{
"require": {
"microsoft/windowsazure": "*"
},
"repositories": [
{
"type": "pear",
"url": "http://pear.php.net"
}
],
"minimum-stability": "dev"
}
When I run the composer.phar I get the following result:
Onwijs#JEROENVINK /e/Users/Public/Documents/00_speeltuin_azure/newsdk
$ php composer.phar diagnose
Checking composer.json: OK
Checking platform settings: FAIL
The xdebug extension is loaded, this can slow down Composer a little.
Disabling it when using Composer is recommended, but should not cause issues bey
ond slowness.
Checking git settings: OK
Checking http connectivity: OK
Checking disk free space: OK
Checking composer version: OK
Onwijs#JEROENVINK /e/Users/Public/Documents/00_speeltuin_azure/newsdk
$ php composer.phar install
Loading composer repositories with package information
Initializing PEAR repository http://pear.php.net
Installing dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for microsoft/windowsazure 0.4.0 -> satisfiable by mi
crosoft/windowsazure[v0.4.0].
- microsoft/windowsazure v0.4.0 requires pear-pear/http_request2 * -> no mat
ching package found.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your min
imum-stability setting
see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> f
or more details.
Read <http://getcomposer.org/doc/articles/troubleshooting.md> for further common
problems.
I don't see what I'm doing wrong.
There seems to be a problem with pear and the Azure SDK via composer.
I found a way around it by modifying my composer.json file to look something like this:
{
"require": {
"microsoft/windowsazure": "*",
"pear-pear.php.net/http_request2": "*",
"pear-pear.php.net/mail_mime": "*",
"pear-pear.php.net/mail_mimedecode": "*"
},
"repositories": [
{
"type": "pear",
"url": "http://pear.php.net"
}
],
"minimum-stability": "dev"
}
Notice the three lines:
"pear-pear.php.net/http_request2": "*",
"pear-pear.php.net/mail_mime": "*",
"pear-pear.php.net/mail_mimedecode": "*"
these provide more explicit information to composer and using this approach things seem to compose just fine.
Hope that helps.
Related
I've created a simple test wordpress plugin. The plugin consists of a single php file (kreplach.php) and a composer.json:
kreplach.php
<?php
/*
Plugin Name: kreplach
Plugin URI: http://gitlab.example.com/sales/kreplach
Description: just a test
Author: Foo Bartok
Version: 1.0
Author URI: http://example.com
*/
?>
composer.json
{
"license": "MIT",
"name": "sales/kreplach",
"type": "wordpress-plugin",
"description": "just a test",
"authors": [
{
"name": "Foo Bartok",
"email": "foo#example.com",
"homepage": "example.com"
}
],
"require": {
"composer/installers": "*"
}
}
On my dev server I have the following composer.json
Server's composer.json
{
"repositories": [
{
"type": "composer",
"url": "https://wpackagist.org"
},
{
"type": "vcs",
"url": "git#gitlab.example.com:sales/kreplach.git"
}
],
"require": {
"php": ">=5.4",
"wpackagist-plugin/akismet": "*",
"wpackagist-plugin/contact-form-7": "*",
"wpackagist-plugin/wordpress-importer": "*",
"sales/kreplach": "master",
"johnpbloch/wordpress": "4.*",
"composer/installers": "*"
},
"extra": {
"wordpress-install-dir": "wp"
}
}
What I think SHOULD happen:
Composer looks through the git repo for composer.json
Composer matches the name "sales/kreplach" found in the build host's composer.json
Composer copies the contents of the master branch into wp-content/plugins/kreplach on my build host.
My fake plug-in does nothing, as designed.
What actually happens:
Bitter, bitter failure.
Loading composer repositories with package information Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- The requested package sales/kreplach could not be found in any version, there may be a typo in the package name.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting
see <https://getcomposer.org/doc/04-schema.md#minimum-stability> for more details.
Read <https://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.
I have tested cloning the sales/kreplach repo onto the same host I'm attempting to install the plugin on.
To make sure that composer is actually reading the composer.json file from the git repo, I introduced a typo (yeah, totally on purpose, like) which threw a "hey, this json file is broken, Foam Head" error.
My version of gitlab is omnibus edition 8.6.4 (installed today).
I have successfully done this same sort of trick with pip/requirements.txt to install custom python modules, so I'm not unused to following directions. Am I missing a step, or some sort of non-obvious (to me at least) nomenclature?
Update 2021, 5 years later, since GitLab 13.3 (Aug. 2020), GitLab (even in its free edition) has a Package Registry, establishing GitLab as a private repository.
You can publish in it Composer packages, and, with GitLab 13.11 (April 2021):
Use Composer v2 with the GitLab Package Registry
You use Composer to publish, share, and download your PHP dependencies to your GitLab Project. Six months ago, a new major version (v2) of Composer was launched with a variety of changes, including significant performance improvements, architectural updates, and runtime features.
You can read more about the changes here.
Until recently, you couldn’t take advantage of these improvements because the GitLab registry didn’t support Composer v2.
This prevented some of you from using the GitLab registry at all.
As an MVC, we focused on adding support for the mandatory parameter metadata-URL. We added a new endpoint GET group/:id/-/packages/composer/p2/:package_name, which returns the metadata for all packages in your repository.
When Composer looks for a package, it replaces %package% with the package name and fetches that URL.
This means we’ve added a new endpoint GET group/:id/-/packages/composer/p2/:package_name which will return the metadata for all packages in your repository.
Please note that there are two parameters considered optional.
We have issues open to add support for the providers-api and list-api parameters. We hope to prioritize them in an upcoming milestone.
See Documentation and Issue.
And (still GitLab 13.11, April 2021):
Download Composer dependencies from version control
You have two options when downloading Composer dependencies: source or dist. For stable versions, Composer uses dist by default and downloads the dependency as a zip file.
However, you can also download it directly from version control.
If --prefer-source is enabled, Composer downloads your dependency as a Git clone instead of as a packaged zip file.
This is useful if you want to make a bug fix for a project and get a local Git clone of the dependency directly.
Until recently, you could not use the prefer-source and related preferred-install commands and configurations when downloading Composer dependencies.
This prevented many of you from using the GitLab Package Registry for your Composer dependencies.
We are happy to announce that you can now download your Composer dependencies from source.
Do so by simply adding the prefer-source option to your install command like this: composer update --prefer-source.
See Documentation and Issue.
I've not used gitlab but have used this method quite a bit with Bitbucket and GitHub.
You need to specify "sales/kreplach": "dev-master" in the server's composer.json - note that the branch name must be prefixed with "dev-".
Apparently Composer has special support for GitHub and BitBucket, which may not exist for Gitlab...so you may need to specify git as the repository type rather than vcs.
Good luck!
Refs:
https://lornajane.net/posts/2014/use-a-github-branch-as-a-composer-dependency
https://getcomposer.org/doc/05-repositories.md#vcs
https://getcomposer.org/doc/05-repositories.md#git-alternatives
I'm having difficulty getting the PHP client libraries package for Windows Azure via Composer. The problem would appear to be around Pear dependencies the package has.
The contents of the composer.json file:
{
"require": {
"microsoft/windowsazure": "dev-dev"
},
"repositories": [
{
"type": "pear",
"url": "http://pear.php.net"
}
]
}
The output following running "composer update" reads:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for microsoft/windowsazure dev-dev -> satisfiable by microsoft/windowsazure[dev-dev].
- microsoft/windowsazure dev-dev requires pear-pear/http_request2 * -> no matching package found.
I've never experienced any difficulty getting this package in the past. I can provide more verbose logs on request.
I recall seeing a few issues raised due to changes in how replaces works in regards to pear bridging.
This issue needs to be fixed upstream to have pear-pear/* replaced with pear-pear.php.net/*, but as a workaround in your root composer.json you can explicitly require the dependencies in order to have them discovered by the solver.
{
"require": {
"microsoft/windowsazure": "dev-dev",
"pear-pear.php.net/http_request2": "*",
"pear-pear.php.net/mail_mime": "*",
"pear-pear.php.net/mail_mimedecode": "*"
},
"repositories": [
{
"type": "pear",
"url": "http://pear.php.net"
}
]
}
The above composer.json should work in the latest and future versions of composer. Tested with Composer version aa9c257f0efd1a54c93ba95282821a497bc15d75 2014-03-09 15:09:15
This is a composer bug, I fixed it by using an older version of composer. Your composer.json is fine. The version I used was:
Composer version 42c496752ab6ec6c45b185b70c8c39220da01b1c
https://github.com/composer/composer/archive/42c496752ab6ec6c45b185b70c8c39220da01b1c.zip
I have a library foo/foo-lib which requires a specific commit from GitHub:
{
"name": "foo/foo-lib",
"repositories": [
{
"type": "vcs",
"url": "https://github.com/KnpLabs/Gaufrette.git"
}
],
"require": {
"knplabs/gaufrette": "dev-master#2633721877cae79ad461f3ca06f3f77fb4fce02e"
}
}
and it works fine:
$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
- Updating knplabs/gaufrette dev-master (2633721 => 2633721)
Checking out 2633721877cae79ad461f3ca06f3f77fb4fce02e
Generating autoload files
but when I require that library in other project:
{
"name": "bar/bar-app",
"repositories": [
{
"type": "vcs",
"url": "ssh://git.example.com/foo-lib"
}
],
"require-dev": {
"foo/foo-lib": "dev-master"
}
}
it yields dependency error:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for foo/foo-lib dev-master -> satisfiable by foo/foo-lib[dev-master].
- foo/foo-lib dev-master requires knplabs/gaufrette dev-master#2633721877cae79ad461f3ca06f3f77fb4fce02e -> no matching package found.
So my question is: how to correctly require the specific commit from GitHub in my library, so that it would be available in dependent packages?
You'll have to explicitly require the Gaufrette library at that hash, with a dev flag, in both your library and your application. Something like this should work in the application composer.json:
{
"name": "bar/bar-app",
"repositories": [
{
"type": "vcs",
"url": "ssh://git.example.com/foo-lib"
}
],
"require-dev": {
"foo/foo-lib": "dev-master",
"knplabs/gaufrette": "dev-master#2633721877cae79ad461f3ca06f3f77fb4fce02e"
}
}
From the documentation:
If one of your dependencies has a dependency on an unstable package
you need to explicitly require it as well, along with its sufficient
stability flag.
The documentation also suggests that you'll need to include the repository for Gaufrette in your bar/bar-app Composer file, though it sounds like this wasn't necessary in this case. I'm not sure why.
Here is how you do it on the command line:
composer update knplabs/gaufrette:dev-master#2633721 --with-dependencies
You don't have to use the whole hash, a hash seven characters long seems to dothe trick. As mentioned above, your project will need to support dev - which it will complain about if not already set. Also, use --with-dependencies to get any dependencies of the one you are updating.
If you're making changes for a Git Repository by forking make sure that you use the
The package name is actually defined in the package's own composer.json file - so even though I'd forked the package to my own joshuapaling github account, and the package was now residing at the URL https://github.com/joshuapaling/Cake-Resque.git, that had not influenced the package's name at all, from composers perspective.
A stupid error - but I'm new to composer, and it wasn't clear at first! So, I hope this helps someone else with the same problem.
I have two projects on my git repo server. The first one is a library I wrote, let's call it foo/lib-bar. The second is an application which uses that library foo/app-bar. Currently the library is in development version, so the composer.json file of the library looks like this:
{
"name": "foo/lib-bar",
"description": "Bar library",
"version": "1.0.0-dev",
"type": "library",
"require": {
"php": ">=5.4",
"ext-posix": "*"
}
}
The application uses this library, so it contains the necessary requirement:
{
"name": "foo/app-bar",
"description": "Bar application",
"version": "0.5.0-dev",
"type": "application",
"repositories": [
{
"type": "vcs",
"url": "ssh://user#git.example.com/lib-foo"
}
],
"require-dev": {
"foo/lib-bar": ">=1.0.0-dev",
},
"require": {
"php": ">=5.5.3"
}
}
And everything is smooth up to this point: both composer install and composer update run as expected, install the dependency and I can see it in vendor/
Now, the docs says that
require#
Lists packages required by this package. The package will not be installed unless those requirements can be met.
And for the steps which lead to the issue in question:
So ok, my library is ready to be deployed and come out of the development phase. It also happens to be required in production version of my application. I remove the dev suffix from the composer.json file of my library, commit and push the file, and am ready to update the application.
With the application's composer.json I move the library dependency from require-dev section to require and remove the dev suffix (everything is copy-pasted, so there is no typo - I've checked and rechecked again):
"require-dev": {},
"require": {
"php": ">=5.5.3",
"foo/lib-bar": ">=1.0.0"
}
Now I run composer update and I get:
$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for foo/lib-bar >=1.0.0 -> satisfiable by foo/lib-bar[dev-master].
- Removal request for foo/lib-bar == 9999999-dev
I assumed it did not find the new version, so I deleted the old library manually:
$ rm composer.lock
$ rm -rf vendor/foo/
and tried to install it from scratch
$ composer install
but this time it gives me:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- The requested package foo/lib-bar could not be found in any version, there may be a typo in the package name.
So it seems like require-dev does work, but require doesn't. Any suggestions on what may have gone wrong here?
require-dev is not the place to develop dependencies. It is meant for software that is used only in development, like PHPUnit, Mockery etc., or for dependencies that are useful by themselves, but in this case only used for development, like the client library for the service a software package is about (to make some real requests in a test scenario).
So your library shouldn't have been "require-dev" from the beginning.
Another thing is: Composer will deduct the version if use appropriate branches and tags, i.e. a branch named "1.0.x" in your repository will be detected as being the development branch for all 1.0 versions, and any requirements for such versions could possibly be satisfied by this branch - provided you allow for development versions either by setting "minimum-stability": "dev" (which would allow development versions for ALL software - rather unintended), or when you require version "1.0.0#dev" for your software.
The one thing that might currently break your composer setup is that you mention a version in the librarys composer.json explicitly, and this is a development version. Have you removed that version indicator? You should remove it, because life is easier if Composer can detect the versions from the tags in a repository, not by having them explicitly mentioned in composer.json.
Finally please make sure that when using Git you tag the commit with appropriate version. The required version should correspond to the git tagged version.
I am trying to add a local project A as dependency to project B. Using git daemon I am able to fetch project A as dependency, but the dependencies defined with require in the composer.json in project A are not recognized. What am I missing?
project A:
{
"name": "project/a",
"require": {
"monolog/monolog": "dev-master"
}
}
project B:
"repositories": [
{
"type": "vcs",
"url": "git://localhost/home/user/project-a"
}
],
"require": {
"project/a": "dev-master"
}
result (in project B):
vendor/
project/a
expected:
vendor/
project/a
monolog/monolog
The most likely explanation is that you forgot to commit the changes to your composer.json in /home/user/project-a.
To debug this you can use composer show project-a dev-master -v. The -v will output more verbose info while it loads the repository, and then you will see details about the version you are installing, if it does not contain the monolog require, then I would say my guess above was correct. If it does contain it, we got a serious bug in composer and you should report it on github.
I encountered a similar issue and my issue was that I was running composer update instead of composer install and one of the libraries that I required defined some of its dependencies as zipballs from GitHub.