I am using the Composer package Omnipay in my project and I want to add a new class to the package (in my case it is support for a new payment gateway). The naming does not conflict with anything and it follows the same naming and structure conventions as sibling folders. However, when I run composer update it deletes my whole folder of changes even though it didn't need to. Is there a way I can tell composer not to delete that directory?
Leave everything under /vendor alone, don't change any files there. You should treat libraries as external dependencies - don't check them into source control or change them in any way. Just reference them in your own code.
If you need to customize a composer library, you can either work around it in your own code (most PHP libraries support dependency injection, which will let you override any of the libraries' classes), or alternatively you can fork the library on github, then reference your own fork in composer.json, or submit the pull request so everyone can benefit from it.
As far as I'm aware, you cannot add to a Composer package as it is external and therefore out of your control. You should treat the packages as libraries only, and add all classes into your own project, ensuring that the packages you need are still set up in your .json file
Related
I would like to test Intervention Image. It looks like a nice package. The installation instructions say:
The best way to install Intervention Image is quickly and easily with
Composer.
The sentence above implies there's also a inferior, slower and difficult, way to install it. I assume the author is referring to an installation without Composer? That is exactly what I am looking for!
However, I am unable to find a way to do that. I have looked for an autoloader file, or even any autoload call in the code. There's none. No documentation either. It seems that only an installation with Composer is supported in a meaningful way.
Has anybody of you tried to use Intervention Image without resorting to Composer?
The way without composer is simply to fetch the source from github, move it in one off your vendor directories and load all needed files.
As there's no autoload file provided inside the package, you have to extend your own autoload script or register a new autoload handler, as including each required file is a really annyoing task.
If you take a deeper look inside the composer.json file, you may notice inside the require section, that this package also need Guzzle. If you want to install Guzzle, you will again read the sentence "The recommended way to install Guzzle is through Composer". So you have to do the same thing again for Guzzle. This time you need the other two Guzzle dependencies psr7 and promises....
At this point, I hope you build your autoloader robust enough to simply add only a new mapping from namespace prefix to path, as their might be many other required packages.
If you don't want to include composer directly inside your project, for what reasons ever, you could also create a empty composer project, just for managing the dependencies and the autoloader. That might be easier to do everything by hand.
Note: If you are lucky, you could use the Intervention/Image package
without the guzzle dependency.
Our current development setup uses a single Subversion repository containing multiple projects, each with branches, tags, and trunk. We then use a "sparse checkout" to select the projects, and branches of those projects, to work with.
The result is that the directory structure of a working copy matches that of the repository, including branch information, and we never use svn switch. (This style of working will probably be familiar to anyone who uses SVN, but may be surprising to those who don't.)
We are thinking of using Composer to manage both external and internal dependencies, but I'm not sure how this can work with the sparse checkout style of working.
I would like some way of using a directory within the existing checkout to satisfy a dependency, rather than each "root project" needing a separate copy.
For example:
sites/Foo/trunk
depends on lib Aaa, so references lib/Aaa/trunk
depends on lib Bbb 1.5.*, so references lib/Bbb/branches/release-1.5
sites/Bar/trunk
depends on lib Aaa 1.0.*, so references lib/Aaa/branches/release-1.0
depends on lib Bbb 1.5.*, so references lib/Bbb/branches/release-1.5
At present, if I edit the code in lib/Bbb/branches/release-1.5, I can test those changes on both sites, without needing to commit one and update the other.
Is there any way of using Composer to manage these dependencies?
(PS: Please don't answer with "give up on SVN, use Git, it is teh awesomez"; that is an answer to a different question.)
No - I do not believe that you can do this with Composer as standard: it expects to copy the files from whichever source (Packagist/VCS/Zips) to the local vendor folder, which is not what you want.
That said, I believe there are two potential ways you could get this working (at least in part):
Autoloader
You could try using the autoload field in the composer.json file to include the correct files into the project. You would still need to manage the checkouts of the relevant branches/versions manually (like I assume you do now), but you would be able to manage the inclusion of the internal libraries through Composer. This will probably require that your libraries are properly namespaced. The paths to the files for each namespace are relative to the root of the project, but can go below the root (via the /../ path) if required.
To be honest though, if you already have an autoloader for these files, there may not be much advantage to this solution. Relevant Docs
Composer Plugin
You could also write a composer plugin/"custom installer" that could probably manage this. This would have the advantage that you could have it manage checking out the correct parts of the sparse repository to have the correct version available, as well as doing correct wildstar version checking, but would be a much more difficult and riskier venture.
The basic process would be that you would define a new package type (e.g. 'internal-svn-package'). You would create the plugin as an external library that gets installed normally via Composer, which declares (via it's composer.json) that it handles this new type of package. Your custom logic would then be used for any packages that are listed with this custom type. I'm not sure how much of the internal composer logic for SVN checkouts you would be able to reuse however. Relevant Docs
I am writing a 1 page script to do a relatively simple task. So I decided to use Flourish Unframework which provides a bunch of cool classes that can used separately.
I only want to use specific classes, say fDatabase, however composer let's download the entire package!
I know I could just delete the unwanted files BUT is there a way that composer could just let me require specific files?
This is not what I am looking for because it's just autoload and note installing 1 file from an entire package.
please assist.
possible duplicate of this but has not been answered too!
Composer only allows installing the whole package. Only installing the files necessary to run the only one function you need is next to impossible to do in general, because the file/class you need might have code that needs one other class.
How to detect that class? Classes can be instantiated with variables, the classname could be concatenated with several strings. Composer would have to detect and possibly execute the code that creates class names.
If you are really concerned about uploading too much code, you could either search for a more appropriate package with less files, do the installation of this package yourself and remove the things you don't need, or simply just use it the way it is.
The project I'm working on requires using the PHP SDK's from multiple 3rd parties. Two of these are Amazon Web Services and the Google API Client (for Google+), and both of them use Composer to manage their files / dependencies. I'm not sure how to best set it up code / structure wise, though, because I don't need both AWS and Google loaded together. I might need AWS in one area and Google in another, so I don't want to just autoload everything every time and have the additional overhead from libraries I don't need right then. Right now I have the structure set up like this:
awscode.php
googlecode.php
libs
composer.json
composer.lock
vendor
autoload.php
aws
google
So, everything Composer related is in a shared composer.json file, and all vendor files in the single vendor directory. But, I can't seem to find a way to just load up say AWS. It wants me to use the autoload.php from what I can tell, which seems to want to load up everything.
Do I need to set it up more like this if I want control over each library?
awscode.php
googlecode.php
libs
aws
composer.json
composer.lock
vendor
autoload.php
aws
google
composer.json
composer.lock
vendor
autoload.php
google
I'm obviously new to Composer and how to best utilize it, and want to make sure that I am setting it up the best way for both my situation, and for future management.
When using Composer, it only loads the classes when they are actually called in your code. To my knowledge this uses the PHP spl_autoload_register.
So in answer to your question, there won't be a significant extra overhead (if any).
Autoloading means that the file which defines a class gets read when you first use that class.
You should include all your project dependencies in one composer.json, they won't be loaded in files you don't use them in.
i was working in my application and i'm using some packages, but i have the necessity to change or add some logic in it. I read that we must don't change code of the packages when they are on the vendor directory, but i didn't find how i can do instead. any ideas?
This differs from package to package.
The one-size-fits-all solution is to fork the package, essentially copying it and modifying code in the replicated version.
Often, packages may offer methods to extend or build on their work. This will be very dependent on the package, and I'd suggest you refer to it's documentation for more help down that front.
If you take the first route, you must be aware of some things:
The second you fork a package, you will be responsible for maintaining it.
If you fork the package, you will end up with a package that cannot be maintained by it's original author because you have changed it. If you keep it in composer and edit the original package, it will get overwritten the next time you run composer update. Additionally, if you're versioning your work, your package modifications will not be carried across. but if you fork it properly, it will have no ties to the original package. This means that your package may become outdated unless you spend effort maintaining it's updates.
If you're using composer, this will most likely involve forking the original package repo and modifying code in that repo instead. (Do NOT do this to just your local package files). This is probably the best solution, because it means if the original repo has made changes to it's package, you can perform merges with your repo to bring their updates into your code (whilst not affecting your changes unless the update does directly interact with the code you're modfying). From there, add your new forked repo into your composer.json file and work with that.