I have seen that many Julia projects seem to include a file in the test folder called "runtests.jl". Is there something significant about that file name or can I have my testing file called whatever I want?
As noted in the package manager docs, when you run test in the package manager while you have a particular package activated, it will default to looking for a runtests.jl file. From the docs, it does not appear there is a way to override this naming convention so it should be assumed the entry point for you unit tests should be the runtests.jl file.
Related
When developing packages in R all R source files are put in the subdirectory R/, and all compiled code is put in the subdirectory src/.
I would like to add some organisation to files within these folders, rather than have everything dumped at the top level. For example, lets say I'm hypothetically developing a client-server application. Logically, I would like to organise all my client R source files in R/client/ and all my server R source files in R/server/.
Is it possible to organise code in subfolders when developing a package, and if so, how? The Writing R Extensions manual doesn't offer any guidance, nor does R CMD build detect files stored in subfolders under R/.
You can't use subfolders without additional setup (like defining a custom makefile). The best you can do is to use prefixes: client-a.r, client-b.r, server-a.r, server-b.r, etc.
Expanding the comment to Hadley's IMHO incorrect answer:
Look at the Matrix package (written by R Core members) which has five folders below src/, and two of these contain other subfolders. Other example is the Rsymphony packages (co-)written and maintained by an R Core member.
Doing this is not for the faint of heart. R strongly prefers a src/Makevars fragment over a full src/Makefile in order to be able to construct its own Makefile versions for the different subarchitectures. But if you know a little make and are willing to put the effort in, this is entirely doable -- and being done.
That still does not make it recommended though.
I argued with R core team Allow for sub-folders in "package/R/" directory . They seem not really want improve it. So my workflow is as follows.
1) Create an R project same as other packages but allow sub-directories in folder R/ such as
R/mcmc/a.R
R/mcmc/b.R
R/prediction/p1.R
R/predection/p2.R
2) When I need to pack them, I convert all files under R/ as
R/mcmc_a.R
R/mcmc_b.R
R/prediction_p1.R
R/predection_p2.R
...
with my package.flatten() function
3) Then I install the flattened version to R.
I wrote a simple script for Linux to do everything
https://github.com/feng-li/flutils/blob/master/inst/bin/install.HS
Recognizing the thread is a bit old, I just thought I'd throw in my solution to this problem. Note that my issue is similar, but I am only concerned with preserving folder hierarchies in development.
In development, I organize my script files in subfolders to my heart's content, but rather than fight R's flat hierarchy in production, I added my own "compile-time constant", so to speak.
That is, in every file located in a subfolder (not in top-level scripts/), I add the following:
if (!exists("script.debug"))
script.debug = FALSE
Then, I load whatever other dependencies are required as follows:
source.list <- c(
"script_1.R",
"script_2.R",
"script_3.R",
"script_4.R"
)
if (script.debug)
source.list <- paste("./script_subfolder/", source.list, sep="")
lapply(source.list, source)
The default assumption is that the code is in production, (source.debug = FALSE), so when in development, just ensure that source.debug = TRUE and the project's script/ folder is set as the working directory before loading any script files.
Of course, this example's a bit simple - it assumes that all script file dependencies exist in the same folder, but it seems a simple issue to devise a system that would suit more complicated development folder hierarchies.
I have a NuGet package that I have created for my company. It works great. But it includes some code in the System.Net.Http.HttpClient.OAuthClient namespace that is very chatty in the logs at the Information level.
I would like to have my NuGet package automatically add the following line:
"System.Net.Http.HttpClient.OAuthClient": "Error"
At the end of the Logging->LogLevel section of the appsettings.json file of the project it is installed in (if its not already there).
Or failing that, is there a way to suppress these logs down to the Error LogLevel in code?
It's just my personal opinion, and it doesn't answer your question directly, but it did not fit into a comment, so posting it here.
I don't think it's up to your package to decide, what will be in the appsettings.json. There may be let's say production and test appsettings, and in test developers of some projects would actually want to see as many logs as possible.
If your package would modify it, you would take away the decision from developers who use your package. Or, imagine, the project that uses your package also used System.Net.Http.HttpClient.OAuthClient namespace, but for its own purposes. And developers again might want to see logs coming from that namespace.
I'd suggest just to put this info into your package's documentation, and than developers of each project shall decide for themselves, whether they want to suppress logs or not.
Update after comment:
Probably this will get you somewhere: http://www.roundcrisis.com/2014/08/03/Nuget-install-tricks/
The basic idea is that you can distribute init.ps1 script together with your nuget package that will run on installation of the package. And with powershell you could do pretty much anything, including replacing strings in text files.
Have a look also at this SO question: Execute an action after my nuget package is installed
When you are using Minecraft forge, it creates an external /mods/ folder that you place your mods in. Is there a way to package all the mods, configuration settings (like splash.propreties) and assets into a single .jar file for ease of distribution?
I am making a custom mod pack, and I don't like the fact that you have to install forge, then download the mod pack, then install the mods in order to run my mod pack. Is there a way to package it into a single jar so that you can just add it as a profile in the launcher and not have to do anything else?
I also need to be able to modify configuration files like splash.propreties, and I would like these to be packaged into the jar as well.
Note: I do not want to use premade launchers like Twitch or Technic.
I'm not aware of a way to package all of your mods into a single jar; there is such thing as a 'fat jar', but it's not what you're after. StackOverflow is intended more for code so you might find some more helpful advice over on the Forge forums.
That being said, you could utilise a Self Extracting Archive (SFX) such as IExpress or 7zip to package all of your mods into one, compressed, file which when executed can extract the mods into the right place. As for having one profile, as I'm sure you're aware, within your /mods directory, you can have another directory for profile-specific mods. So you could have your mods extract to a /mods/modpackname/... directory. Forge doesn't have great documentation but this writeup explains the process step by step.
Hope that helps
I try to find and also to delete all the unused libraries in a project. For example I have a folder lib/ with lot of other folder which are the famous libraries. I want to know how I can identify which libraries are not used.
I asked the same question here but the only response I received suggests to me to check each file one by one ...
Can you help me?
I don't think that is possible, as some libraries may be lazy loaded depending on some internal state of your application.
So even if you could somehow find all strong typed references inspecting the code, you have no way of finding out if a library is loaded via magic methods, custom class loaders, dynamically generated include or require statement, eval-ed code and so on.
Without having tests with 95%+ coverage for your non-library code, it is very risky to remove anything from your lib folder. You code may appear to run fine, but still fail in some edge cases.
There's an open source project that can help you to do that:
https://github.com/composer-unused/composer-unused
Installation
composer require composer-unused/composer-unused-plugin
Usage
composer unused
And if you want to use it inside phpstorm, you can look at their composer documentation: https://www.jetbrains.com/help/phpstorm/using-the-composer-dependency-manager.html#create-and-run-composer-scripts
When developing packages in R all R source files are put in the subdirectory R/, and all compiled code is put in the subdirectory src/.
I would like to add some organisation to files within these folders, rather than have everything dumped at the top level. For example, lets say I'm hypothetically developing a client-server application. Logically, I would like to organise all my client R source files in R/client/ and all my server R source files in R/server/.
Is it possible to organise code in subfolders when developing a package, and if so, how? The Writing R Extensions manual doesn't offer any guidance, nor does R CMD build detect files stored in subfolders under R/.
You can't use subfolders without additional setup (like defining a custom makefile). The best you can do is to use prefixes: client-a.r, client-b.r, server-a.r, server-b.r, etc.
Expanding the comment to Hadley's IMHO incorrect answer:
Look at the Matrix package (written by R Core members) which has five folders below src/, and two of these contain other subfolders. Other example is the Rsymphony packages (co-)written and maintained by an R Core member.
Doing this is not for the faint of heart. R strongly prefers a src/Makevars fragment over a full src/Makefile in order to be able to construct its own Makefile versions for the different subarchitectures. But if you know a little make and are willing to put the effort in, this is entirely doable -- and being done.
That still does not make it recommended though.
I argued with R core team Allow for sub-folders in "package/R/" directory . They seem not really want improve it. So my workflow is as follows.
1) Create an R project same as other packages but allow sub-directories in folder R/ such as
R/mcmc/a.R
R/mcmc/b.R
R/prediction/p1.R
R/predection/p2.R
2) When I need to pack them, I convert all files under R/ as
R/mcmc_a.R
R/mcmc_b.R
R/prediction_p1.R
R/predection_p2.R
...
with my package.flatten() function
3) Then I install the flattened version to R.
I wrote a simple script for Linux to do everything
https://github.com/feng-li/flutils/blob/master/inst/bin/install.HS
Recognizing the thread is a bit old, I just thought I'd throw in my solution to this problem. Note that my issue is similar, but I am only concerned with preserving folder hierarchies in development.
In development, I organize my script files in subfolders to my heart's content, but rather than fight R's flat hierarchy in production, I added my own "compile-time constant", so to speak.
That is, in every file located in a subfolder (not in top-level scripts/), I add the following:
if (!exists("script.debug"))
script.debug = FALSE
Then, I load whatever other dependencies are required as follows:
source.list <- c(
"script_1.R",
"script_2.R",
"script_3.R",
"script_4.R"
)
if (script.debug)
source.list <- paste("./script_subfolder/", source.list, sep="")
lapply(source.list, source)
The default assumption is that the code is in production, (source.debug = FALSE), so when in development, just ensure that source.debug = TRUE and the project's script/ folder is set as the working directory before loading any script files.
Of course, this example's a bit simple - it assumes that all script file dependencies exist in the same folder, but it seems a simple issue to devise a system that would suit more complicated development folder hierarchies.