what is the convention for specifying meteor requirements? if for example I want to add to a github repository. for other to easily deploy.
some thing like python requirements.txt.
The requirements are located in the .meteor/ directory in the packages file. Simply add the .meteor/ directory to your git repository and the requirements will automatically be downloaded when the user runs meteor.
Related
I am trying to use meteor typeahead package in my project. It has some issues with it, so the developer asked me to create a local PR and use it. The thing is that I don't know how to create a local PR. Do I need to create a local package and then add it to my project, etc. I cloned the repository to my local machine, and changed the code that I need, but I don't know what to do after this. Can somebody help me with this please.
Thanks
After you cloned the package just copy all the files in a packages/name_of_the_package folder of your Meteor project.
You can also create a symbolic link between the package folder and the package folder in the Meteor project. So all changes are automatically reflected.
Then, add it as usual with meteor add name_of_the_package or by modifying the .meteor/packages file. Meteor will look in priority in the local package folder instead of the official repository.
Create a fork of the desired repo.
Clone your fork of the repo as a sub folder of the "packages" folder within your app.
Remove the atmosphere package by performing a meteor remove some:package
Add the package back, just as you normally would, with meteor add some:package. Meteor will find the local copy and use it, instead of downloading the package from Atmosphere.
Make the desired code changes, testing it before you commit.
Commit your changes to Github.
Create a pull request within the fork on Github.
If you want to use a package between two projects, what's the best way to handle it. Considering two scenarios :-
First Scenario
Git Repository with the two projects like
root folder
-- Mobile App Folder
-- Web Folder
So both projets are in the same repository
Second Scenario
Each project is in separate Git repositories and we want to share the package between those projects.
What's a good ways to handle each scenario? ( Either using the same method for both, or different methods for each scenario)
You need to be aware of how Meteor handles package scanning when confronted with meteor add package :
searching for it inside the local packages/ folder of your app.
searching for it inside every folder specified in the PACKAGE_DIRS environment variable.
searching for it on Atmosphere.
Not sure about the specific order but I'm assuming the one that makes most sense.
So your question is basically where to store the package for an optimal workflow.
Using the fist scenario, you would store your private packages inside the app root folder under packages/, you'll just have to git pull from the repo to get the latest versions of the packages. Then you would have to make sure to define correctly the PACKAGE_DIRS env variable, something like this :
export PACKAGE_DIRS=$PACKAGE_DIRS:$HOME/meteor/my-repo/packages
Using the second scenario, you would store each private package on its own git repo, then pull them into a local $HOME/meteor/packages of yours and don't forget to set PACKAGE_DIRS appropriately.
export PACKAGE_DIRS=$PACKAGE_DIRS:$HOME/meteor/packages
I would tend to go with the second scenario if there's a chance that these private packages may be reused for other projects, if you are sure they only make sense in a particular project, then storing them along in the repo is OK.
Another option would be to symlink your shared private packages into the "packages" folder of each of your apps.
So assume you have have your shared package in the folder /dev/mysharedpackage. You could create a symlink via ln -s /dev/mysharedpackage packages/mysharedpackage and then add the package via meteor add.
Here is a Meteor Cast on this topic: https://www.meteorcasts.net/ep/3
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.
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.