I am trying to implement a repository for my libraries which are repositories, and added as sub-modules of the main repository, so the development of each library can be separated from each other and the composer require have to look at only the main repository
My Repository structure is something like this
Main repositoey
----Submodule 1
----Submodule 2
----Submodule 3
----...
This structure is needed because if, i want to share the library to anyone, then they only have to add the main repository to their composer.json and not every single repository for the library.
I have tried similar thing using the branches and tags but, that is not feasible when more than one libraries with same version, we can not create duplicate tags for different branches, which is possible for the submodules.
What i want to implement is
Create modules
Push on the bitbucket repository
Share the module internally with colleagues
They should be able to get the module by running composer require vensor/module
And they do not need to add another repository
I do not know this is the correct direction i am heading in.
Please guide me or suggest a better way to implement the same mechanism.
Personally I don't like git submodules. It is better to create separate git repository and add composer package with packagist(public code) or satis(internal usage).
You can create package and publish it then you can add it to require in your composer.json then if you modify package you don't need create a new 2 commits in main repository and in submodule.
Related
I have a composer project for which I need to create a custom plugin that will also use composer. Both the main project and the plugin use the same dependencies but in different versions. How should I resolve these dependencies between each other? So that the plugin uses a dependency from its composer vendor and not from the vendor of the main project?
I found for example this solution: https://github.com/TypistTech/imposter-plugin but it doesn't seem very elegant to me.
Compare as well with another recent Q&A Dependency Conflict between Plugin and Theme which should add more general clarification.
As you normally use Composer to resolve dependencies you could also use it here. However there seems to be a little misconception or at least some lack of clarity in your question:
So that the plugin uses a dependency from its composer vendor and not from the vendor of the main project?
In a compoer project, there is only one vendor folder, the one of the root project, the one you likely meant by "main project".
This paired with the description of only a "Project" and a "Plugin" there might be a slight chance that it is either one project which has its dependencies managed by Composer ("Project") of which one dependency is the "Plugin".
Or you have just two independent projects ("Project" and "Plugin") that can work independent to each other (normally not the case for "Plugin" material).
At the end of the day it is less a question of Composer, but just whether your software projects dependencies can resolve or not in a compatible manner.
As PHP has a global namespace and it is static, if you really have incompatible dependencies across the same software packages, you need to fork these and rename the namespace so that you can have one dependency for your module A and one for module B. So next to your a "Project" and a "Plugin" you also have projects you manage the dependency packages in, e.g. rewriting Namespaces and then offering to composer via a repository.
I'd like to know what's the best practice
using git for a project using external
library/modules/framework.
Put the case I deploy a project with zend 2
and some modules for instance ZfcUser and BjyAuthorize
should I put it in the repository or not ?
When a developer clone the project get the framework
and modules or not ?
Thanks in advance.
In the case you're using composer to manage your project dependencies, no need to push ZF2, ZfcUser and BjyAuthorize. Just add your composer.json package descriptor and ignore your vendor folder to push your project.
If you're managing dependencies by yourself, i think it can be useful to push all your libraries. (that's how i did for many ZF1 projects where i had embedded some libraries).
I strongly urge you to use composer or any tool like it as you don't have to worry anymore about framework / libraries updates.
If the framework exists as a git repository I would consider using git submodule add yourFramework which will put a reference to the framework in your repository that others can download.
The overhead associated with adding some frameworks to a repository is probably trivial seeing as that code shouldn't get touched. It might just be easier for you to add the framework into the repository to reduce the work that other developers would have to do in order to start working.
I have a home-made framework which contains two types of bundles. Application bundles and dependencies. Application bundles are specific to the application (can be a news module, administration, etc.). Dependencies are libraries which I re-use in several projects.
For every new project, I start by adding the app bundles and dependencies. Until now I kept a separate copy of these bundles and copied them manually into my project.
I rarely need to modify dependencies. However with application bundles, I always have to customize the views and controllers, so they are meant to be modified in all the projects they are used.
I want to improve the way I manage these bundles and thought of using Composer. However, it does not comply very well with the application bundles, as you are not supposed to modify the packages. I would need to be able to install packages for once, then ignore them in the next updates (they become part of the application source code).
I could add some override mechanism (copy classes to another directory, which would override the default bundle classes) as Symfony does I think, but I don't like this idea. It just adds unnecessary complexity.
Could use another bundles management system, or even a custom one, but then this means no access to Composer packages, which would be great.
Using Composer for dependencies and another system for the application bundles would be messy..
How would you handle it?
It it should run on unix, use apt, yum, yast ...
Simply try to build your own dep / rpm pakages.
Build foreach application bundle and depencencies bundle.
That add at theapplication bundle the depencencies bundle as depends.
Or do you looking for something like pear?
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
I'm fairly new to git (vcs in general) so I need help with this next case.
I want to start working on a new project, which will be built using php lithium framework, and doctrine 2.
Case:
I have a main project git repository, and now I want to add (clone) lithium framework inside, from github.
Next, I need to clone li3 extension for doctrine 2 (it automatically clones itself and doctrine 2).
Questions:
Is this the right way (I suppose not).
How do you manage cloning inside existing repository (especially that second part, with li3 extension and doctrine 2).
Thanks in advance.
In git there is no such "cloning inside existing repository" (well technically there is but let's don't make this more complicated than needed). What you describe looks like that you want to use the lithium framework and doctrine as a library.
Normally you don not need to put external libraries into your repository. You only need to do this if you plan to modify the library code and put it under version control.
But you should think first about what you would like to do: integrate it into the repository or not. I think the later is the easier one.
You just create your own git repository first. Then you exclude that part of the library folder that you don't want to have under version control. So you can keep things apart quite easily in the beginning.
To set this up, first create your project on disk w/o git. Create the file system and directory layout. Then initialize the git repository within the project's main directory. That's just calling git init inside that directory.
Git will now show the status of all files you have in there when you type git status. Before you do the first commit you can use the methods described in gitignore(5) Manual Page to exclude the libraries and (perhaps configuration files of your IDE) that you do not want to have inside the git repository.
You can always check if the configuration you're editing matches your need by checking the output of git status.
Keep in mind that git ignores empty directories, so if there is a folder you don't want to be added, it will start to show in the status only if it contains at least a file.
When all the files you don't want to have under version control have disappeared from the status listing, you can do your first commit: git commit -m "Initial Commit.".
Depending if you have configured git or not, it will give you an error about your name and email. The error messages point you to what you need to know. It's just that you have an author and email for each commit, which is useful.
And that's it already. Check the web for the commands:
git init
git status
git commit
it's quite easily with git help *command*, like git help init. It takes some time to learn git, so probably create some test-repository to play around. Once you've learned the commands and get used to it (in case of doubt, google your problem), it's supercool to use.