I've modified some files in one of vendor package and I know git will not commit those changes.
What would be the best approach to commit my change? Move Package out of vendor?
If I run composer update, I believe my updated code will be reverted?
Thank you for the help.
Yes when you run composer update your changes will be reverted.
Use git add /vendor/package/editedfile.php, full path of file to upload live.
But keep in mind this is not pure solution ;)
Related
I'm new to opam and trying to figure out how to use it properly. For a class, I want to set up students with an environment that has some custom packages installed. (The package will consist of some raw .ml files that I got from a colleague at another school; the files are on their github but there's no .opam file that I can see, and as far as I know they're not in any official package release.)
Can I somehow call these local .ml files a package and ask opam to install it? Do the files have to be on github first, and if so can I use my colleague's existing repository as the source? I don't want to make any of this public, since it is not my own work; I just want to configure my local environment so that the code in the files can be included easily as a package. Basically I don't know the best way to proceed so I'm happy for any advice.
You can add a custom opam file in the base directory of the project. See the documentation for how to create that file.
Then you can enter opam pin add . in the base directory and your project will be installed as if it was an opam package. Check opam pin --help for more info (you can also pin to a remote git project for instance).
Note that though the default repository is hosted on github, this is in no way a requirement for opam. Opam is dependent on git but you can absolutely use it with a private git repository. If you want to use your colleague's repository as the source, that is totally doable though it is often preferable to have the opam file at the root of the directory (you can do a PR on their repository or make your own fork of it on github, the site makes it clear you copied the code).
If pinning is not to your taste, you can also create your own repository though this is probably a bit too heavyweight for your needs.
Good luck!
So, I'm enjoying using composer, but I'm struggling to understand how others use it in relation to a deployment service. Currently I'm using deployhq, and yes, I can set it to deploy and run composer when there is an update to the repo, but this doesn't make sense to me now.
My main composer repo, containing just the json file of all of the packages I want to include in my build, only gets updated when I add a new package to the list.
When I update my theme, or custom extension (which is referenced in the json file), there is no "hook" to update my deployment service. So I have to log in to my server and manually run composer (which takes the site down until it's finished).
So how do others manage this? Should I only run composer locally and include the vendor folder in my repo?
Any answers would be greatly appreciated.
James
There will always be arguments as to the best way to do things such as this and there are different answers and different options - the trick is to find the one that works best for you.
Firstly
I would first take a step back and look at how you are managing your composer.json
I would recommend that all of your packages in composer.json be locked down to the exact version number of the item in Packagist. If you are using github repo's for any of the packages (or they are set to dev-master) then I would ensure that these packages are locked to a specific commit hash! It sounds like you are basically there with this as you say nothing updates out of the packages when you run it.
Why?
This is to ensure that when you run composer update on the server, these packages are taken from the cache if they exist and to ensure that you dont accidentally deploy untested code if one of the modules happens to get updated between you testing and your deployment.
Actual deployments
Possible Method 1
My opinion is slightly controversial in that when it comes to Composer for many of my projects that don't go through a CI system, I will commit the entire vendor directory to version control. This is quite simply to ensure that I have a completely deployable branch at any stage, it also makes deployments incredibly quick and easy (git pull).
There will already be people saying that this is unnecessary and that locking down the version numbers will be enough to ensure any remote system failures will be handled, it clogs up the VCS tree etc etc - I won't go into these now, there are arguments for and against (a lot of it opinion based), but as you mentioned it in your question I thought I would let you know that it has served me well on a lot of projects in the past and it is a viable option.
Possible Method 2
By using symlinks on your server to your document root you can ensure that the build completes before you switch over the symlink to the new directory once you have confirmed the build completed.
This is the least resistance path towards a safe deployment for a basic code set using composer update on the server. I actually use this method in conjunction with most of my deployments (including the ones above and below).
Possible Method 3
Composer can use "artifacts" rather than a remote server, this will mean that you will basically be creating a "repository folder" of your vendor files, this is an alternative to adding the entire vendor folder into your VCS - but it also protects you against Github / Packagist outages / files being removed and various other potential issues. The files are retrieved from the artifacts folder and installed directly from the zip file rather than being retrieved from a server - this folder can be stored remotely - think of it as a poor mans private packagist (another option btw).
IMO - The best method overall
Set up a CI system (like Jenkins), create some tests for your application and have them respond to push webhooks on your VCS so it builds each time something is pushed. In this build you will set up the system to:
run tests on your application (If they exist)
run composer update
generate an artifact of these files (if the above items succeed)
Jenkins can also do an actual deployment for you if you wish (and the build process doesn't fail), it can:
push the artifact to the server via SSH
deploy the artifact using a script
But if you already have a deployment system in place, having a tested artifact to be deployed will probably be one of its deployment scenarios.
Hope this helps :)
I have installed Laravel and and I am playing around with it.
I am following the tutorial :-
http://geekanddummy.com/how-to-laravel-4-tutorial-part-3-using-external-libraries/
I need a new library and have added that in composer.json.
But when I run
php composer.phar update
I get the following message :-
Composer could not find a composer.json file in
What do I need to do to get this corrected..?
I'm the author of the tutorial you link to (hope our Laravel tutorial series is of some use, by the way). I can't quite tell from your answer whether you restored all the content of the original composer.json file when you created a new file of the same name...? You definitely shouldn't need to nuke the composer.json file and start again. As you probably know, that file contains all the Composer-based dependencies for your Laravel project, so you would of course lose significant functionality if you were to wipe it and leave anything out when you start again.
The error message looks to me like you're either in the wrong directory or it's a permissions problem with the composer.json file. It's too late to be certain now, but if you come across the problem again, try running:
chmod a+r composer.json
at the console/ssh shell before running composer update. This restores read permissions (for all users). You may also wish to check file ownership. (Both commands assume we're in a Unix/Linux system, so YMMV.)
Watch out also for instances where you're running a Composer command with the global parameter. This will cause an change that relates to wherever you've installed Composer, rather than the directory you're currently working in.
Note that you can also update using the --working-dir parameter, thus:
php composer.phar --working-dir=/path/to/laravel/project update
Hope this helps.
Rob
Deleting the existing composer.json after copying the content and then saving a new file with the same name works.
If your on windows (at least in my experience) you actually use just 'composer', not composer.phar/.json or any extension.
composer update
composer dump-autoload
This is all I need to type in to be able to access composer in my laravel directory.
i had the same issue, tried several many solutions that worked for others but not in my case.
then some-one told me to drop the 'php' and '.phar' from my command. i.e. directly use
composer update
composer create-project etc.etc.
and to my surprise it worked..
Occasionally, and for reasons that remain a bit vague, restarting the server seems to solve the issue. That step might be worth trying before making changes to file permissions.
Go to https://git-scm.com/download/win
Then download related version and run your composer command inside the git bash
Or else you can use vscode bash;
enter image description here
I have a java project in Intellij and use Hg/Mercurial for version control. I ignored some files with this .hgignore file
syntax: glob
target/*
.idea/*
*.iml
and deleted all these files which was committed before. but now I can't execute my project, cause it can not find the file misc.xml.
What should I do?
Updated answer for IntelliJ 14+: File-> New-> Project from Existing Sources... (choose your project directory) and follow the wizard Q&A.
Restarting Intellij should fix the problem. Just make sure you click on the "Import Project" pop-up that appears on the top right.
At first, you shouldn't really ignore everything under .idea but instead only .idea/workspace.xml and .idea/tasks.xml, as it JetBrains states: http://devnet.jetbrains.com/docs/DOC-1186
To solve your problem and get your project back to working state there are possibly two solutions:
Checkout the last commit that contains the files under .idea folder with
hg checkout SHA,
where SHA is the commit id.
After that reset your working space to the head:
hg reset HEAD
Edit your .hgignore in the way that was recommended before, add project files to stage, and commit them:
hg commit -am "Reverted project settings"
If there is no commit with the project settings, you can just import your code back.
Start Intellij IDEA and choose "Import Project". Choose the folder with your code, and choose the appropriate SDK after.
I met this problem when I did rm -rf project command, then when I git clone a new project to my working space, maybe quit the idea and then import the project again. This can easily solve this
I have found that for this error and also for some other cases where the IDE project behavior is inconsistent with command line behavior, the following often helps: close the project's Intellij IDEA window, delete .idea/, and open the project again. IntelliJ often flashes up a message saying it didn't find a project root but generally this disappears after a few seconds and IntelliJ automatically rebuilds the .idea directory.
Recreating the .idea folder
File -> Close project
File -> Open -> Choose pom.xml under the project folder -> Open as project -> Delete existing project and import
we are working with mercurial and now we would like to introduce precommit hooks to keep the code clean. We would like everyone to somehow get the hooks, but we would also like to be able to update this in some centralized way. Mercurial does not version control hooks, so what would be our alternative option?
Do any of you have found a solution for this?
Thanks in advance!
Nemmi
Hooks are not cloned (as detailed in "Version-controlled extension configuration in Mercurial"), but you can have a common hgrc file (see hgrc Syntax):
A line of the form %include file will include file into the current configuration file
In that central configuration file, you can then modify the [hooks] section.
If you have control over their desktops (it's a standard corporate install) you can put the hook in the system-wide entries /etc/mercurial/hgrc or /etc/mercurial/hgrc.d/ourcommithook
If you're remotely administering the machines you could automate this using something like the very excellent puppet or by building your own .rpm, .deb, or .msi installer which both installed Mercurial and places the everyone hooks in the machine-global config.
Have a look at the projrc extension. You then simply need to have designers put a small number of common lines in their ~/.hgrc files and they will automatically get pushed whatever you put in your centralized repo's repo/.hg/projrc file.
You will still need a common place to put these hooks but you probably already have some sort of shared mounted drive that users all mount, right? Or you could have a "tools" repository that everybody has to have checked out in a standard location.
Steve