This is probably a pointless question but figured theres no harm in asking.
I have inherited a website which from what I can gather is using some Zend libraries and Doctrine... I think, excuse my ignorance as I'm not very clued up on the Zend framework.
In anycase I have been asked to update the numerous instances of depreacated code in among it. Which I thought would just have been within the application code so I could just update functions here and there etc etc.
It turns out most of the code needing updated is within the library folder which from what I can gather is all libraries which I would have thought would have been set up using composer but theres no mention of a composer.json file within the codebase.
So im now at a loss as I have a bunch of libraries that I have no idea how to update. Which brings me to my question, what would be the best way to attack this problem?
I was thinking if there was someway to reverse engineer a composer.json file based on the contents of the aforemetnioned library folder, that would be a good start as I could then use that as the basis for replacing the library folder with the updated libraries pulled in by composer but I have a feeling im probably clutching at straws.
To give some idea, this is the top level folder structure of the library folder:
Given the amount of subfolders within those listed and all the dependencies no doubt involved I would imagine manually updating them would be a nonstarter.
Would be interested to get thoughts on the best course of action here.
If I were in your spot I would create a composer.json and add try to add the libraries from the folder one by one and check if the app still works and fix dependencies one by one, I also see there is a vendor folder in there, that may have been the result of a composer.json which could be easily added in a new composer.json, but you will have to take the libraries one by one.
Related
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'm wondering what the best way (if there is a way) for an application to auto-discover [relevant] PHP "packages" installed by Composer.
My use case specific scenario:
I have a PHP app that includes my "framework" (for lack of a better word). This framework brings some basic functionality (routing, admin etc).
I'm slowly building in more advanced functionality, say, a blog module. This module is entirely self contained in it's own directory (but obviously has dependencies on the framework).
I'd like this blog module to be a self contained Composer package, so that I can selectively require the package in my app's root composer.json file.
Now, I need for the framework to know that it's there so that it can, for example, set the routing correctly and load up any admin functionality that the module requires.
What I've thought so far:
I'm relatively experienced in PHP, but "proper" OOP and autoloading is a little bit beyond my knowledge at the moment, so please forgive if there are inbuilt functions to do this. I don't even know what terms to Google!
I have thought I could maybe read the installed.json file which composer puts at vendor/composer/installed.php but I'm not sure how to set up my packages (e.g. blog) so they announce what they are. I'd like to future proof it so that I'm not looking for known module names (or regexing vendor or package names), but rather looking for packages to say "hey framework, I know you! You can use me!"
Maybe I can somehow instruct Composer (through the package's composer.json file) to stick in an arbitrary key/value pair in installed.json?
Any suggestions welcome, or directions as to what sort of Googling I should be doing.
Oh welcome to the world of managing dependencies on your framework.
I have some experience with auraphp, where we dealt with similar issue. You can read the blog post Composer-Assisted Two-Stage Configuration .
So what we finally ended-up adding https://github.com/auraphp/Aura.Web/blob/a3870d1a16ecd3ab6c4807165ac5196384da62cd/composer.json#L26-L36 these lines in the packages that need to understand to load by the framework.
You can also see how this bundle can also get autoloaded with the configurations.
in your composer.json
https://github.com/harikt/Aura.Asset_Bundle/blob/6ea787979390e69bf6ecb1e33ce00ed90f306e2f/composer.json#L21-L27
and the config/Common.php ( https://github.com/harikt/Aura.Asset_Bundle/blob/223126cedb460e486c4f0b242719c96c14be5385/config/Common.php ) , note we have other development modes also. For a detailed look check https://github.com/auraphp/Aura.Web_Project or https://github.com/auraphp/Aura.Framework_Project
Hope that helps a bit to look into the code and work on your own solution.
i'm building a new project on top of CodeIgniter MVC framework, but now that i'm looking at the design, i will actually not use most of the framework features except for 1.form validation, 2.router and 3.session/cookie/input handling, and 4.views generation
even for database i will use Redbeans php ORM.
So my question
how can i glue these components that i fetched with composer from other frameworks so i can inject them into my project and be good to go without other extra stuff that i don't need ?
would it be a wise decision ? or is there any risks of depending on components rather than whole framework ?
i have googled a lot but it seems like i'm using the wrong keywords or something, i could not find any tutorial except for this one -which dictate symphony- that teach you how to do this and what are the risks of doing it
You can take a look at Packagist to explore which components Composer offers, RedBeanDB is definitely in there. However, in contrast to Symfony, CodeIgniter is not really Composer-friendly. So if you are looking for a proper way to just load these few CodeIgniter components as a dependency, I guess you're out of luck.
To keep from digressing, I'm simply going to answer your two main questions:
1) There are plenty of tutorials out there on how to use composer to grab your packages, so I wont do a full writeup, but basically what you need to do is download composer, create a composer.json file, then run composer to have it download all those packages and their dependancies. All you then need to do is in one of the already loaded codeigniter files, autoload the autoload.php file
`require 'vendor/autoload.php';`
Check the composer documentation here on how to download composer and setup your json file.
2) Definitely. The Laravel framework is actually built this way under the hood, instead of writing everything themselves, they use composer to pull in packages from other projects like Symfony to do certain tasks.
For example, if I want to remove composer from fuelphp... is there any easy way to remove composer?
I mean I ask to use fuelphp (or some framework else) without composer.
Since composer is part of the framework. You "Do" need it. Period. Otherwise you have to follow #Sven's advice.
Having said that, you often only have a need for composer on your development platform, since that is where you'll want to pull the new code or updates in.
It's perfectly fine to deploy your application (to a staging or production environment) without composer, and without the .git folders. You would not want to have updates pulled in in those environments anyway, all code on these platforms should be under your version control.
No, there is no "simple" way.
To do what Composer does, you'd need to have:
Download all the libraries in the correct version that are directly included.
Also download all libraries that are required by any library in step 1.
Repeat downloading new libraries in step 2 unless you do not find any new, i.e. you completely downloaded all these.
Then create an autoloader for every downloaded library depending on what every configuration for every library said has to be done, i.e. either register a PSR-0 (or PSR-4 if some libs like to live on the edge), or parse the whole source tree for occurrences of classes, interfaces and traits and create an array listing every such class name and the containing file name.
Last but not least find a way to place everything downloaded and created where the regular Composer results would be expected.
Doing this manually is not impossible, but it is ridiculous to do so.
While I do admit that Composer makes it a little bit harder for the uninformed hobbyist programmer to fiddle with his home-brewn scripts when trying to download a new library because he now has to get to know Composer, in the end it makes the lives of everyone much easier - the time invested into getting to know Composer is well invested. Composer will not go away soon. In fact, every other language has something like Composer for a very long time, and nobody complains or tries to remove these dependency managers there.
FuelPHP from version 1.7+ (I think) requires composer, you would have to modify the autoloader to prevent it from trying to use composer's autoloader. This is not advisable as it means it becomes harder to keep up to date with maintenance releases.
Unfortunately for you composer is rather widespread and so is something that you will have to use if you continue working with frameworks. Fuel ships with a version of the composer.phar so you don't even have to go to the bother of downloading/installing it on your system.
If there is no dependencies, you can always simply do something like :
set_include_path(dirname(__FILE__).'/framework_XYZ');
spl_autoload_extensions(".php");
spl_autoload_register();
without forgetting to change the "framework_XYZ" by the directory where the core/system classes are hiding... ;)
J.
I'm working on releasing a PHP framework I have been using for a few years
on github. Been trying to read up on the most correct way a project
should be structured, what extra files such as readme's etc should be
added. Been coming up with blanks on google. Can anyone point me to a
project that's a good example or any good write ups.
Some PHP projects hosted on Git(hub) include:
CakePHP
Gallery3
Garden
PHPUnit
Kohana
I'd just make sure that no temporary files, etc. get in the repository by creating a .gitignore file, and add some readme's etc. to the root of the repository.
Any configuration files should also be ignored, and sample configuration files should be created in the repository.
I'd recommend writing the readme file in a format that Github supports, like Markdown. It'll make your repository front page look better.
You might want to follow some kind of class naming guideline to make things like autoloading easier to implement. For example, the class MyFramework_Controller should be located at directory /lib/MyFramework/Controller.php.
You should just create some kind of basic layout for now - it'll be easier to give suggestions when we can see what you have right now.