If I understand it correctly, the SymfonyRequirements.php file (which lives under /app or /var depending on Symfony version) is handled by Composer. I therefore suppose it should be not be tracked by any version control system. However, I see it is excluded from Symfony Standard Edition's .gitignore file:
/var/*
[...]
!var/SymfonyRequirements.php
Edit
Symfony core developer #Stof says in a Github issue:
given that one of the checks is whether you installed vendors, it must
be there before installing them (even though we have an automatic
update of the requirements so that you check the uptodate ones next
time).
This is not very clear to me. Can anybody give any more details about this file and explain why it should or should not be tracked by a VCS?
This file is used by Symfony Check CLI Script to check for minimum requirements of configuring & running a Symfony App. It's a Common Post-Deployment Task.
It checks for current PHP Version/Configurations(php.ini settings) and required PHP Extensions. For example it checks for current setting of date.timezone.
What #stof is trying to say is that you should be able to run the checks even before installing dependencies using composer install. It even checks for dependencies installation itself: checks for existence of vendor/composer directory.
It gives you a good & enough insight about whether the Symfony App has what it needs to be run based on Current PHP configuration.
Note that by adding this file to VCS, you should know there may be changes to this file after updating dependencies later using composer update. So you should remember to commit this file too!.
Please Note that these checks also provide some recommendations(not requirements) to be set. For Example check this recommendation out:
When using the logout handler from the Symfony Security Component, you should have at least PHP 5.4.11 due to PHP bug #63379 (as a workaround, you can also set invalidate_session to false in the security logout handler configuration)
Some other Projects using Symfony also implement their own checks by extending this file, For example checkout Oro Platforms Requirements Check.
The files is used in the check CLI tool that use this files for control the minimal Requirements for Running Symfony. You can find more info in the doc.
Usually is take into account in a version control system, as you can see in the symfony-standard distribution project on github:
https://github.com/symfony/symfony-standard
(of course you can add the files in your custom .gitignore files)
For more precision, this file is used in the command php bin/symfony_requirements in symfony3 and php app/check.php for older, that checks your php/symfony requirements.
See this question Should the changes of SymfonyRequirements.php be included in version control? and the documentation.
Related
I have integrated a Service Worker for receiving Push Notifications in my TYPO3 Extension.
Now I want so send Messages form backend to the clients web-push-php Library.
But how it is possible to integrate the library and its dependencies to TYPO3?
If you set up your project with composer you can just require minishlink/web-push and start using class Minishlink\WebPush\WebPush.
In case you‘re running in "legacy" mode (i.e. classic install without composer) or want to support both you‘ll need a different approach. IMO best practice is bundling composer requirements in .phar files - this way you can keep your IDE clean and your VCS footprint small. There‘s a blog post with a detailed description about phar bundling in TYPO3 extensions.
This method works for most composer requirements following PSR-0 or PSR-4 and should be viable in your case as minishlink/web-push seems to follow PSR-4.
You can even advance this by using scripts you can launch by running composer run <script> in your extension‘s root folder. TYPO3 extension typo3_console holds a composer.json defining such scripts.
If you need to run your extension in a TYPO3 6.2 environment you‘ll need to remove composer.json from extension folder as 6.2 fails coping with "real composer requirements" (i.e. non-TYPO3-extension packages).
I recently downloaded a new symfony2 package for websockets and included it into my composer file,
when I called
php composer.phar update
It automatically updated my Symfony version and I was wondering if updating Symfony2 will break the website in the long run, since part of my source code could become obsolete (deprecated)
Yes, if composer downloads a version of a dependency that's not backward compatible with the version that you used to develop your website, things might/will break.
However, you can limit the possibility by defining good rules in your composer.json.
First of all, it might be good to learn about semantic versioning if you haven't heard of it already. Many projects are following the rules of semantic versioning, which basically state that if a project/library has changed in a way that is not compatible with earlier versions, it's main version number should be incremented. For instance, if 1.5.x had a certain feature, and an update is made where that feature is changed or no longer available, the new version number should be 2.0.x instead of 1.6.x.
Knowing this, you can use Composer's tilde operator (~) to define useful version constraints. For instance, to add the dependency to symfony's files, you can add the following requirement to your composer.json:
"symfony/symfony": "~2.3"
which is equivalent to:
"symfony/symfony": ">=2.3,<3.0"
or, in plain English: 'give me a version of symfony/symfony, at least version 2.3 or higher, but lower than 3.0'. If Symfony follows semantic versioning correctly, no backward incompatible changes should be made in any 2.x versions (and, if any backward incompatible changes are made, they should come with version 3.0), so you should be fine.
This actually depends on how your composer.json is configured. If your dependencies use SemVer, and you are referencing them in your composer.json only allowing patch version changes (like "package-name": "1.1.x"), then everything should usually be fine.
Also, note that you can pass a package name as a parameter to the composer update command, e.g. php composer.phar update <vendor/dependency-name>. This will tell Composer to only check if there are updates available to <dependency-name> package, given your current composer.json version constraints.
If you want to check that nothing is broken after an update and you're not keeping the update scope as narrow as I specified, then something could break. The best way to detect and avoid this is by testing.
You should read about composer.lock file. This will make sure that Composer will not update any version of the repository and only what you specify in the lock file
I am using Spring Source Tool Suite 2.8.1 to implement Spring applications.
I frequently get build errors because references are lost for no apparent reason. In Right-click project in Package Explorer->Properties->Java Build Path->Order and Export, I find projects sometimes are deselected. And often packages are gone in Right-click project in Package Explorer->Properties->Java Build Path->Deployment Assembly.
Having to reset these settings frequently is frustrating. Is there some way I can work around these problems?
I have tried to update STS to the latest version, but the upgrade process fails with incomprehensible error messages. I want to avoid a clean install because setting up the environment again would probably be a nightmare.
Now that I know this is a maven project and you are adding references yourself, this is making sense to me. STS 2.8.x was the last STS to ship with the legacy m2e (maven plugin for Eclipse). It did not recognize build path entries added manually (it likes to have complete control over the classpath). So, what is likely happening is that you are adding these classpath entries and then an update project operation gets kicked off automatically. This will have the effect of removing all of your extra classpath entries.
You are best off doing the following:
Updgrading STS
Or just upgrading your m2e component (you will have to first uninstall the old m2e, but this should be taken care of automatically from the discovery update page).
Or, just accept the fact that you can't manually change your classpath with the legacy m2e.
I have a private bundle that I import in the vendor.
Now, I'm working in my project and want to edit some code in the vendor bundle.
Now I've done that and want to commit to code, so I go the dir of that bundle and say: "git commit -a" so I give a message, save and now I have a commit. Oke, "git push" and give the response "Everything is up-to-date"... So I can't push that but I can commit??
Is this not a way to commit? Should I just clone the repo and work there?
You should never edit the vendor code directly - this is the whole point of dependency management.
Composer basically works by looking at your composer.json file, and fetching the repositories and versions you specify. If you need to make changes to one of your dependencies, you should make the change in the original repository, push the changes up to GitHub (or wherever you're hosting the code) and run composer update.
When Composer installs a vendor, it checks out a particular commit, so you are not on a branch. You need to checkout the master branch — or whichever you're using — and commit to it and push it.
Its a long time ago that I asked this question. Mean while I got the answer but never updated my stackoverflow question, sorry for that!
The answer on my own question is to get the dependency with composer --prefer-source.
https://getcomposer.org/doc/03-cli.md#install
--prefer-source: There are two ways of downloading a package: source and dist. For stable versions composer will use the dist by default. The source is a version control repository. If --prefer-source is enabled, composer will install from source if there is one. This is useful if you want to make a bugfix to a project and get a local git clone of the dependency directly.
I have almost finished the development of a project developed with Symfony2, and wish to put the project online.
However, I suppose there are a lot of things that need to be done so that everything works ok. I suppose, the dev mode needs to be disabled etc....What needs to be done and how?
What are the most important things to do on a Symfony2 project that will be available to everyone on the web?
I suggest you to use Capifony for deployment. It does a lot of stuff out of the box and you can make it run any custom commands you need. See its documentation for details.
Regarding the dev mode, unless you've removed the IP checks from app_dev.php, you don't have to worry about deploying it. Of course, if you wish, you can tell Capifony to delete it on deployment.
The best way to handle deployment is to create "build" script, which will:
Remove all folders and files with tests from your bundles and vendors.
Remove app_dev.php file
Make sure that app/cache and app/logs are fully writable/readable.
Packs your project into archive (rpm f.e.)
Then, before deployment, you should create tag in your project - so it will mean, that certain version of your application is released (I recommend to follow this git branching model).
Create tag.
Run your build script
Upload archive to host
Unpack
Enjoy your project
Im currently researching the same thing.
The first thing you have to consider is "how professional" you want to deploy. There are a lot of tools you can use:
Continous Integration Server ( e.g. Hudson, Jenkins)
Build Tools (e.g. Phing, Capistrano --> Capifony, Shell scripts)
Versioning Tools (e.g. Git, SVN)
I think the simplest setup is using only a Build tool and i guess you are already using some kind of versioning.
Depending on which tool you use, the setup is different, but I think there are some things you should consider with your application (maybe not all are applicable to your application)
Creating a Tag in your Versioning
Copying the new Code in an folder on production
--> if you are in a new folder you dont need to clear the cache and logs, since these shouldnt be in your versioning the first time.
loading composer (if youre using it)
installing vendors
updating database schema
install assets from your bundles
move symlink from current version to the folder of the new site
These are the things I currently need for my application for production deployment, if you deploy to an test environment you should load fixtures and run your testscripts as well.
One other option that is very well described here is to deploy the Symfony2 application with Apache Ant. Apache Ant is a Java library and command-line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other.