Seems like something that would have been asked/answered already but I cannot find anything related to this.
I have some CSS files that came with some packages. I want to not utilize a particular CSS file. Everything else in the package is great, but I'm having to use a lot of specificity to override the default styles it launches with, and it just seems hacky to override instead of remove.
I also don't want to just delete the file because I will likely want to update this package as new versions are released.
Is there some Meteor.ignore('thatCssFile.css') method of doing this?
The simplest way is probably to fork this package on github and clone it (git clone https://github.com/author/package.git package-clone) as a local package of your app (in my-app/packages/).
Then you can edit the package.js file of the cloned package and simply comment the api.addFiles directive where the problematic CSS is added.
Synchronizing with the package maintainer would be only a matter of git pulling the latest commits from the source repo.
You'll need to meteor remove author:package first and then add your local clone using meteor add package-clone.
Answer is correct, unless the cloned repo uses git submodules, in which case you must do:
git clone git://github.com/foo/bar.git
cd bar
git submodule update --init --recursive
I realize this is a bit late but another solution would be to use the meteor-postcss package and configure the excludedPackages option.
Related
I used devtools::install_github... in R to install a repository and also installed the repository by using git clone in terminal. What's the difference between these two routes? So far, I understand that I can then use library(package) in R and will load the package in, whereas when I've cloned the GitHub repository, I don't think the package is immediately available. Can anyone explain the difference between these two methods?
Thanks!
git clone is a general way to check out a local copy of any git repository. It doesn't know about R at all or how R packages work. The devtools::install_github() (which is really just remotes::install_github()) checks out a copy of a repository and then does the extra work of actually building and installing the package so R can use it. Also it removes the local copy of the raw source files after it installs. If you just want to run/use the package, use remotes::install_github(). If you want to edit/contribute to the source code for a package, then use git clone to get the code.
devtools::install_github is an R function that attempts to install a package directly from GitHub repositories (Link to Documentation). This allows to install packages automatically from GitHub. You can specify multiple repositories in a single call to the function like this (Example from the previous link that attempts to install multiple repositories):
install_github(c("rstudio/httpuv", "rstudio/shiny"))
git clone is a console command that clones a git repository, by copying all the files (Link to Documentation). You only can clone one repository by command, and you may need to build and install the package after cloning it. Also, you can clone from hosts different to GitHub, like BitBucket, GitLab, or a custom git server. You can clone a repository like this (Example from the previous link that attempts to clone a repository from a host different to GitHub):
git clone git://git.kernel.org/pub/scm/.../linux.git my-linux
I want to add a feature to FITSIO package and submit a pull request. What is the current workflow for that? Before Pkg 1.0 there were Pkg.checkout and Pkg.submit functions. Are there similar commands that I can run in Pkg v1.1?
Of course, I can manually fork the repository on Github, make changes and submit a pull request. But I wonder if there are convenient shortcuts in Pkg 1.1 for that?
Update
Here is a useful guide that I found.
You can use Pkg.develop (or the develop Pkg REPL command) which will download a full git-clone of the package and put it in $HOME/.julia/dev by default. There you can make your changes and push as usual.
Pkg.develop can also take a path as an argument, so if you have git cloned the repository to some other more convenient folder (as compared to $HOME/.julia/dev) and prefer to work there you can "install" that path by Pkg.develop(PackageSpec(path = "path/to/clone")) and it should be available to load from within Julia.
EDIT:
checkout has been replaced by two new things:
if the intention is just to install the master branch of the package you now do pkg> add Example#master (or Pkg.add(PackageSpec(name="Example", rev="master")));
If the intention is to modify the code you use Pkg.develop.
There does not exist something like Pkg.submit in the new package manager; you have to git push and make a PR yourself.
I am trying to follow this tutorial, in order to install the Nix package manager in my home directory instead of /nix.
I am doing the PRoot installation (see 2. in tutorial). At the end, the
tutorial proposes to be smart in Building native packages section, to be
able to run packages without PRoot:
To run packages natively (without PRoot) they have to be build from source because all paths to the nix store are hard-coded. It is simple, really:
mkdir $HOME/nix
nix-channel --update
env NIX_STORE_DIR=$HOME/nix nix-env -i nix
And now your Nix store gets built up using the new paths. The built binaries can be run directly from there.
I did that, but I don't see how it frees me from PRoot. If I don't do the /nix mounting point with PRoot, nothing works (no nix-env executable,
I can't install new packages).
Should this NIX_STORE_DIR environment variable be put in my .bashrc ?
It seems I always need to run PRoot because ~/.nix-profile points to
a /nix/... directory:
.nix-profile -> /nix/var/nix/profiles/default
There are more steps in the tutorial (5., 6.) - should I follow them ? It seems they apply only in case of using the manual installation (step 4.),
although it is not explicit.
Any help would be appreciated :)
For anyone stumbling on this old question: there is no currently supported way to install Nix without root. The above wiki was moved to https://nixos.wiki/wiki/Nix_Installation_Guide . It may well be out of date. PRoot could work, but even then, rebuilding the whole store at a different path is not a good idea, not the least because the binary caches won't help and you'll need to build everything.
I suggest trying Nix in a virtual machine or cloud server.
Future people from Google, it's still unsupported but does work. Script here that installs a couple dependencies, builds a temporary Nix, and uses that to install a proper version in your directory of choice.
I'm using Meteor 0.9.3, and I want to try to make some changes to a Meteor smart package. I'm using the package in my app already, let's call it: author:smartpackage.
First, I removed my reference to the published package:
meteor remove author:smartpackage
I've forked the repository on GitHub, and made a local clone in:
/somedir/meteor-smartpackage/
I've created a directory in my meteor app:
/meteor/myApp/packages
and created a symlink:
ln -s /somedir/meteor-smartpackage /meteor/myApp/packages/meteor-smartpackage
How do I now add this local package into my app? I've tried a variety of
meteor add xxxx
options, but I can't find the right command. Am I even close?
The steps you described look good to me, so maybe this is the symlink stuff which is messing around.
The proper way of maintaining private packages is to have a packages/ directory somewhere in your filesystem, let's say in ~/meteor/packages, then you have to set a special environment variable that is called PACKAGE_DIRS, which is looked up by the meteor command line tool to find local packages that reside out of official package repositories.
So let's set this environment variable in your .bashrc and resource it :
echo "export PACKAGE_DIRS=$HOME/meteor/packages" >> ~/.bashrc;
. ~/.bashrc
Then assuming your forked package resides in ~/meteor/packages, meteor add author:package should work normally.
Update to saimeunt's answer, for Meteor 1.2+
I found that loading the local package requires leaving out the author when running meteor add.
Loads Local Package
meteor add cocos2d-meteor
Loads Remote Package
meteor add jakelin:cocos2d-meteor
I've published a few packages in beta state to Atmosphere. Now, in development it turned out some of them are useless (they were consumed by another one). How can I unpublish them?
There is a temporary, undocumented way to do this:
Log into the atmosphere website with the same details you used to publish your package then in your javascript console in chrome, safari or firefox run:
Meteor.call("deletePackage","<your package name>",function(err,result){
console.log(result || err)
});
Replace <your package name> with the name of your package, the same that you could run mrt add <your package name> with.
It doesn't seem like there is a way to do this right now. The only non-local functions are publish and release:
https://github.com/oortcloud/meteorite/blob/master/lib/meteorite.js
However, I agree that this is a feature that definitely needs to be added, so that at least some people who want to clean things up have the ability to do so. Otherwise we'll end up in package hell like npm :)
You should open an issue in the meteorite repo.
I think you just remove them from your smart.json file manually and it will "unpublish" them