You just installed a meteor package, and for some reason it isn't working. You suspect that it's the package itself that has a bug. You want to investigate that. How do you do that?
Optimally, you'd be able to run a command that forks the original package repository with the right version and replaces the original in your meteor application, ready for you to debug it and, once fixed, possibly generate a pull request.
I don't expect something like this to exist as a single command, but is there a workflow that you follow to do exactly that? Or do you approach the problem in a different way?
Do a git clone of the package into your local packages folder. Fix any bugs you need to. Commit them. And make a pull request. Once the pull request is accepted, you can remove the local package and use the regular package.
From when I've asked in the past, there isn't really an easier way to do this it seems. But to be honest, this approach isn't too much work.
Also, if you just want to debug, you can step through the package code while it's running without cloning the repo locally. (Assuming it's running in development mode and hasn't been minified by Meteor).
Related
I've been using numtel:pg package for several projects in Meteor. Since Meteor version 1.8 the package isn't working correctly anymore. Anyone can point me to a solution?
The package seems to be abandoned, since there is no update in 4 years(!).
Trying to fix a package that is this outdated is usually not worth the effort. Your best options in this case are
find an alternative package for postgreSQL integration
find a fork of the package, that has fixed the compatibility issues
fork the package yourself and update the NPM versions or transform the package to run without hard wiring to a specific NPM version.
Resources to achieve that:
https://guide.meteor.com/writing-atmosphere-packages.html#peer-npm-dependencies
https://github.com/tmeasday/check-npm-versions
General Readings:
https://guide.meteor.com/atmosphere-vs-npm.html
https://guide.meteor.com/writing-atmosphere-packages.html
What to do if none of this applies to you, because
The alternatives require a lot of refactoring or even changes in the app architecture
There is no fork that keeps the package maintained
You are not skilled enough to fork and update the package yourself
First you should definitely open an issue on the repo and describe your problem as detailed as possible:
Meteor version, postgre version
Meteor version, postgre version where everything worked
What errors do you exactly get? Best is adding a stacktrace, if possible.
if the "error" is rather undesired behavior (not reacting, things disappear etc.) you need a very detailed description of what you did, what you expected, what (not) happened
Add screenshots if possible
Create a minimal repository that reproduces the error/issue and upload it to github; link it to your issue description
Note, that the points above also apply on Stackoverflow as criteria for a "good question". If the repo owner does not respond after a week you may trigger her attention by using #nameOfOwner in the comments.
More resources can be found here:
https://stackoverflow.com/help/how-to-ask
https://stackoverflow.com/help/mcve
By doing all these efforts you raise the chance of some community members to pick up your error (because there is less effort to reproduce when the error is documented well) and fix the issue or fork the repo.
Last but not least the golden way would be to deal with the issue, read about the package and how it works, check the code and try to fix it. Write some tests, document the fix and finally open a pull request in order to share the improvements with all the other package users.
My enterprise has a Git repository. To make changes, I have to make changes in my forked repository and then make a pull request.
I primarily use RStudio, so I have enabled its integration with Git. I can make changes to my forked repository and then push, pull, sync, etc. The problem is that I still have an additional step of logging into GitHub and making a pull request for my forked repository. Is there a way of doing this from RStudio?
I too use RStudio for R development and I do not believe there is a way to do this. The reason is because this is more than just adding code to a branch, you're requesting a management feature to take place which is pulling part of your code into another branch of the code base. RStudio appears to be limited to pulling, syncing and committing. Likely you need to use a separate, more full featured GitHub client.
This could be done via the GitHub API, which could be executed from an R package using the httr or curl package, after which such a package could have an addin for RStudio, which would let you check everything using a nice Shiny app!
Now we only need to look for someone who wants to develop this… Can’t seem to find it (Jan 2022).
I followed the directions in the buildroot documentation but I think they may be wrong. My patch never gets applied.
To be clear, I am not trying to patch files in the "output" directory, which is what I think the directions are describing. I'm trying to patch files in the "package" directory to fix a problem with one of their recipes.
Does build root not allow patching of buildroot during the build? Or is there some trick to it?
Or do I just need to write a script that will apply the patch before running make?
Also, there is no error generated when building the package in question, during the patch step. Should there be one if the patch is malformed or not appliable?
thanks,
Well, just as you discovered, patching in Buildroot (as well as any other build system), does refer to patching the source code of a particular application. (In this case files unpacked somewhere under output/build).
If you need to fix something in how Buildroot builds a certain package, you'll need to manually patch the packages .mk and Config.in (possibly adding patches etc). I'd recommend you to create a local branch, and do your work there. This will allow you to easily merge in updates from the main Buildroot tree.
If you're fixing build issues or something else that might be of interest to others, please submit the patch to the Buildroot mailing list.
Mostly all of the testing lines printed to the console get in my way, especially when I'm just setting up a new project or trying to get this one code bit down that the testing framework isn't too helpful for. Any help is appreciated!
I was able to disable Velocity via
VELOCITY=0
Before running the server, so basically I ran
VELOCITY=0 meteor run
Keep in mind that creating a new Meteor project doesn't install Velocity or Mocha by default, so if you have them it's probably because they were manually installed or part of a boilerplate project that you're using.
Having said that, I think it's safe to remove these packages. More than likely, if you have Velocity and Mocha installed, you need to run the following:
meteor remove mike:mocha velocity:core
There might be other testing-related packages that need to remove. To find out what other packages are installed for your project, you can run the following:
meteor list
Then just remove individual packages as needed.
In addition to the VELOCITY=0 environment variable, I've found that pressing Ctrl+V in the client window will temporarily disable Velocity on that client, which will stop the tests from printing things in the console. Pressing it again will re-enable it.
In order to be able to compare two versions of a package, I need to able to choose which version of the package that I load. R's package system is set to by default to overwrite existing packages, so that you always have the latest version. How do I override this behaviour?
My thoughts so far are:
I could get the package sources, edit the descriptions to give different names and build, in effect, two different packages. I'd rather be able to work directly with the binaries though, as it is much less hassle.
I don't necessarily need to have both versions of the packages loaded at the same time (just installed somewhere at the same time). I could perhaps mess about with Sys.getenv('R_HOME') to change the place where R installs the packages, and then .libpaths() to change the place where R looks for them. This seems hacky though, so does anyone have any better ideas?
You could selectively alter the library path. For complete transparency, keep both out of your usual path and then do
library(foo, lib.loc="~/dev/foo/v1") ## loads v1
and
library(foo, lib.loc="~/dev/foo/v2") ## loads v2
The same works for install.packages(), of course. All these commands have a number of arguments, so the hooks you aim for may already be present. So don't look at changing R_HOME, rather look at help(install.packages) (assuming you install from source).
But AFAIK you cannot load the same package twice under the same name.
Many years have passed since the accepted answer which is of course still valid. It might however be worthwhile to mention a few new options that arised in the meanwhile:
Managing multiple versions of packages
For managing multiple versions of packages on a project (directory) level, the packrat tool can be useful: https://rstudio.github.io/packrat/. In short
Packrat enhances your project directory by storing your package dependencies inside it, rather than relying on your personal R library that is shared across all of your other R sessions.
This basically means that each of your projects can have its own "private library", isolated from the user and system libraries. If you are using RStudio, packrat is very neatly integrated and easy to use.
Installing custom package versions
In terms of installing a custom version of a package, there are many ways, perhaps the most convenient may be using the devtools package, example:
devtools::install_version("ggplot2", version = "0.9.1")
Alternatively, as suggested by Richie, there is now a more lightweight package called remotes that is a result of the decomposition of devtools into smaller packages, with very similar usage:
remotes::install_version("ggplot2", version = "0.9.1")
More info on the topic can be found:
https://support.rstudio.com/hc/en-us/articles/219949047-Installing-older-versions-of-packages
I worked with R for a longtime now and it's only today that I thought about this. The idea came from the fact that I started dabbling with Python and the first step I had to make was to manage what they (pythonistas) call "Virtual environments". They even have dedicated tools for this seemingly important task. I informed myself more about this aspect and why they take it so seriously. I finally realized that this is a neat and important way to manage different projects with conflicting dependencies. I wanted to know why R doesn't have this feature and found that actually the concept of "environments" exists in R but not introduced to newbies like in Python. So you need to check the documentation about this and it will solve your issue.
Sorry for rambling but I thought it would help.