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
Related
I am trying to get better understanding how renv package in R works and how it interacts with git. Here are my questions
Assume I have master and a couple git branches in my R projects for each (master and branches) I would like to use different environments (different libraries or different versions of the same libraries). Would renv be able to handle it, i.e. if I switch from one branch to another will need to call renv::restore().
I have two separate projects with renv running in both of them, call them project A and project B. I would like to take environment from project B and replace environment in project A. How can I accomplish it? Do I just need to copy renv folder from one project to another?
Assume I have master and a couple git branches in my R projects for each (master and branches) I would like to use different environments (different libraries or different versions of the same libraries). Would renv be able to handle it, i.e. if I switch from one branch to another will need to call renv::restore().
renv excludes the project library from version control (to avoid bloating the repository size), so in normally you would be required to restore the library path when switching branches.
This is a bit arduous, so another solution would be to configure renv to use a different library path for each branch for your git repository. You could accomplish this with something like (in your project .Rprofile):
branch <- system("git rev-parse --abbrev-ref HEAD", intern = TRUE)
Sys.setenv(RENV_PATHS_LIBRARY = file.path("renv/library/branches", branch))
This way, renv would be automatically configured to use a separate library for each branch, and this would happen automatically as you switch branches.
This seems like something that would be useful to have in general; you might consider filing a feature request at https://github.com/rstudio/renv/issues if so.
I have two separate projects with renv running in both of them, call them project A and project B. I would like to take environment from project B and replace environment in project A. How can I accomplish it? Do I just need to copy renv folder from one project to another?
That should suffice, although it depends on how much of the environment you want to copy. The renv folder contains a settings.dcf file, defining project settings -- you may or may not want to copy those settings over as well. (See ?renv::settings for documention on renv's project-specific settings.)
Alternatively, you could copy the project renv.lock from project B to project A, and then call renv::restore(). This might be more appropriate if you were e.g. copying a project from one machine to another, especially if those machines were running on different operating systems.
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.
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.
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.
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.