I am using composer to manage dependencies in a Drupal project. Some modules I have are in mercurial repositories. Once I do composer install I am able to download my Drupal modules from their respective mercurial repositories. The composer.lock file also gets generated correctly.
Now let's say I make changes in one of the repositories. After that, if I run composer install, I expect the changes to get reverted, so that the repository goes back to the revision stored in composer.lock.
But that does not happen. The changes I have made persist. Am I missing something? Is this because am using a mercurial repository?
If I understand this correctly, you change something in your vendor/project and you want to revert there changes, right?
If so, I usually remove vendor/project directory and install package again.
Related
What's the proper way to handle having multiple developers on a Meteor application? On each computer that I want to develop the app on I have to follow these steps to get it running after cloning from the repo:
Rename my-app/ to app/
Run meteor create my-app
Move all files from app/ into my-app/
Delete the auto generated my-app.*files
Re-add all packages (jquery, iron:router, etc...)
Note that I'm not including the .meteor/local directory in the repository.
I feel like I'm missing something obvious but it's not making itself apparent.
Push to the repo all files at the same level as the .meteor directory. Nothing to rename or meteor create. Yes, packages do need to be added, but the list of packages is specified in a file inside .meteor.
Just include the full .meteor/ directory in your repository. That way whenever the repo is cloned they will get the right version of meteor, a list of all the installed packages (which are downloaded at runtime) and any settings they need to run the app.
As far as I'm aware there is nothing in the .meteor/ directory that can't be shared across to different developers.
There are two command line programs to start/stop/manage your meteor app. There is meteor and there is mrt. As of the latest build (0.8.2 or so) it's really not clear what the difference is between these two, if any. Both seem to support the argument "help" like meteor help and mrt help. The output of both seems to be the same to me.
Sadly, I do not see a "clean" argument available when I check the help for either of these. What do I need to do if I want to achieve a clean build? One that would
Blow away all packages and re-install them
Blow away any compiled templates
Blow away all Sass/Less compiled output
I ask this because I find myself in some kind of dependency Hades right now and want out now.
Meteor is still in a pre-release state. So the idea of packages is (still as of this post) not officially supported, though it will be soon. The meteor community stepped in to build their own way to use 3rd party packages and this is what meteorite does.
Most of the commands you give to meteorite are eventually passed to meteor which is why you see the same output.
The only (main difference is) mrt add which checks atmospherejs.com for packages first.
These two will be merged very soon (there is a branch on meteor on github called packaging which seeks to achieve this)
The idea of 'clean' isn't really there in meteor because most of the stuff is based on hot code reloads, so when a file changes its completely scrapped/(cleaned) and rewritten.
If you change a bit of code it will rebuild all this unless you have a syntax error.
Nonetheless if you want to 'clean' the build from everything you would have to do this in two steps (the meteor part and the meteorite part)
This erases some stuff in the hidden .meteor folder
meteor reset
Delete everything in ~/.meteorite/packages
Delete all symlinks only in your projects /packages folder. Be careful not to delete the folders because these will have been put in by you/whoever made your project and wouldn't be from atmosphere or meteor
Then run mrt update to reinstall all the atmosphere packages from scratch
My team has is working on a git repository which contains a fully deployable Wordpress app. This was configured in this way so that it could be deployed to a AWS stack quite easily. The repository contains a caching plugin which creates two folders in the wp-content/ folder named
cache/
w3tc-config/
When devs are checking out this application they are removing the caching features for development and thus the plugin is writing these changes to the two directories it uses. Which then encourages .git to stage them for a commit.
Is there anyway we can ignore these folders on dev machines but not remove them from the repo? Also i'd be interested in hearing other solutions which might help me get round this problem even if it is a larger change.
If you check out your repository and let master follow that, then you can create a devel branch where you just add cache w3tc-config to .gitignore.
I do something similar at work where I use git-svn to work with a svn repository which "links" in another svn repository for a sub module. Git clone did not fetch that sub module, so I just copied in the content from a svn checkout, checked into a devel branch (leaving master following the svn trunk branch), and added the sub module directory to .gitignore.
This is a solution that will require specific action from each developer, and not something you can push out from the repository. But similar to git hooks, if you create a tools/do_it.sh script that does the required actions it is possible to lower the bar considerably.
You cannot have it both ways. Either the files are tracked or they are not. You cannot keep files in the repository but avoid tracking changes to them. Once they are tracked, it is up to you to not git add them. (And it is worth noting that git does not track folders ever.)
Create an archive called UnzipMeRightAfterCloning.zip that contains all the stuff you want ignored. Anyone cloning the repo needs to extract that archive, and it will add all the files/folders blocked by your .gitignore settings. (And given your current setup, you will have to untrack the files in those folders first.)
Put these in your .gitignore file. (Do not put in asterisk.)
cache/
w3tc-config/
Yes, create a local .gitignore file in the project directory.
in the file paste the following
cache/*
w3tc-config/*
Now, these files will be excluded from git, but they won't be removed from the repository.
I want to commit to a Plone package. Do I include it with mr.developer? If yes, the code is in buildout-folder/src. After I made my changes, how do I commit with my existing github account? Should I use something different than mr.developer?
If you have a fork of the package in your github account, then using mr.developer is an excellent way to make local changes.
Just use normal git tools. The repository is indeed located in the src/ directory, just cd to it and use a normal git workflow. Then use GitHub to issue a pull request to the original package for your changes.
All mr.developer does is make it easier to switch buildout to use the development egg stored in src/ and to make the workflow of working with 1 or more repositories for eggs-under-development. It doesn't require you to do anything special with a version-control managed package.
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.