I'm trying to figure out the best/cleanest way to fork an existing package on Atmosphere within a project. I encountered a few occasions where an existing package needed some modifications and I was forced to fork it.
As far as I can tell, the following options exist. Unfortunately, all of these have their own issues and I have yet to find the perfect solution. I will use meteor-router
as an example:
Steps:
packages/router/.git/
packages/.gitignore
and remove the 'router' linesmart.json
packages/router
to your project repository and commitAdvantages:
Disadvantages:
Do not even consider this for any but the simplest packages!
To fork a package on github, your can check your smart.lock
file to see which repository is being used. Go to the github page of that repository and fork it.
Next, you have three options:
More info on git submodules: http://git-scm.com/book/en/Git-Tools-Submodules
Steps:
smart.json
Advantages:
Disadvantages:
git submodule init
the first time and update
to updatesmart.json
to use your versionSteps:
smart.json
, find "router": {}
and add "git": "https://github.com/USER/meteor-router.git"
inside the empty {}
. "branch"
or "tag"
.Advantages:
Disadvantages:
(Suggested Meteorite improvement: allow packages to be installed in an editable form, like Python's pip allows using the '-e' parameter)
"path"
to smart.json
Steps:
"path"
to your smart.json
to point Meteorite to your local checkoutAdvantages:
Disadvantages:
smart.json
, you will most likely break all other development/deployment environments...Which method do you use? How do you work around the disadvantages to that method?
I might have missed some issues with these solutions.
For Meteor 1.0 I recommend the following:
Set up a local packages folder
$ mkdir "$HOME/code/packages"
Add the PACKAGE_DIRS
environment variable to your .bashrc
/.zshrc
file
export PACKAGE_DIRS="$HOME/code/packages"
Fork and Clone the repository
$ cd "$HOME/code/packages"
$ git clone <yourGithubFork>
Install the package from your filesystem
$ meteor add <packagenamespace>:<packagename>
There is an even easier answer than all of the above. Create a directory called packages in your project and put the package you want to override in it. Simple!
Ex: Let's say that you wanted to make some changes to accounts-ui-unstyled (which is a sub-dependency of accounts-ui) from meteor. Do a git clone of the entire meteor source to a local repository:
MyMachine:~ theuser$ cd Development/
MyMachine:Development theuser$ git clone https://github.com/meteor/meteor.git
MyMachine:Development theuser$ cp accounts-ui-unstyled ~/Development/MyProject/packages
In your project structure you would then have this
MyProject
|
-> client
-> lib
-> packages
|
-> accounts-ui-unstyled
-> private
-> public
-> server
-> tests
Any changes you make inside of MyProject/packages/accounts-ui-unstyled will now override the package.
2b. Edit your project's smart.json to use your version
I would recommend this version, as it is the most consistent with how the smart.json
was intended to be used and supported. mrt update
will correctly reflect the latest from the git repo
I think.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With