Is there some way I can read the version variable from my project's .nimble file? Some languages include built in functions that will give you this value, does Nim have one of these functions?
The .nimble file can be parsed with parsecfg. This parsing can be as complex as shown in the documentation with a while loop and considering all possible cases, or you can trust that the .nimble file follows the standard and includes a line like:
version = 0.1.2
In this case you can just search for that case like this:
import parsecfg
var p: Config = loadConfig("./yourPackageName.nimble")
echo p.getSectionValue("", "version")
The empty string passed to getSectionValue points to the root of the config file, and then you extract the version value from there.
Related
Can anyone provide me a link to an example of using named properties in dbx. The documentation mentions an example of a .json file,
https://dbx.readthedocs.io/en/latest/named_properties.html
but it does not mention how we can invoke this file with sample variables. Do I need to write python code to have a file containing these variables?
I have two enviornments and I want to pass on different variables to the deployment.json file.
author of dbx here.
With latest 0.7.0 update we fully support passing both environment variables and variables from file.
Please check:
https://dbx.readthedocs.io/en/latest/features/jinja_support/
for details
The most recent way to passing var is by using the --jinja-variables-file since dbx 0.6.6.
And do not use the env vars, it's not jinja standard.
I am creating a npm library where I need to read the files of the folder from where my library function were invoked from command line and then operate on those files.
By operation I mean to check if a variable exist, if a function exists, modifying variable, function,etc.
The files will be a Typescript files.
Any help on how to proceed will be great.
Seems like you need some kind of AST parser like Esprima or babel-parser. These tools can parse the content of JS/TS files, build the abstract syntax tree that can be traversed, modified and converted back to the source code.
There's a lot of useful tools available in Babel toolset that simplifies these operations. For example, babel-traverse simplifies searching the target statement or expression, babel-types that helps to match the type of the AST nodes and babel-generator that generates the source code from the AST.
It's going to be very difficult to get these answers without running the files.
So the best approach is probably to just import the files as usual and see what side-effects running the files had. For example, you can check if a file exported anything.
If this doesn't solve your problem, you will have to parse the files. The best way to do that might be to use the typescript compiler itself:
https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API
I am trying to customize the color of the LaTeX inline formula when using Sphinx documentation package, and html output.
The details:
I have a file called func.rst, which includes the following line:
Let :math:`x_{1}` be a binary variable.
which is rendered successfully into LaTeX in the documentation I created with Sphinx.
(I have 'sphinx.ext.imgmath' listed in extensions in conf.py)
My goal is to have x_{1} colored in red.
Things I tried:
Adding the color inside the formula:
Let :math:`\color{red}x_{1}` be a binary variable.
while also defining
latex_elements['preamble'] = '\usepackage{xcolor}'
in the conf.py file.
Trying to define all math output globally with:
latex_elements['preamble'] = r'''
\usepackage{xcolor}
\everymath{\color{red}}
\everydisplay{\color{red}}
'''
Needless to say, both (and many more less promising ideas) failed.
Copying over my answer on cross-posted question at tex.sx:
As you seem to be targeting html with math rendered as PNGs images (or SVGs), the current config value to configure isn't latex_elements, but imgmath_latex_preamble.
I tested since and it works.
For completeness sake, I am adding here the full solution. (THANKS jfbu!)
In conf.py I defined extensions = ['sphinx.ext.imgmath', <some_more_unrelated_stuff>]
Also in conf.py I defined
imgmath_latex_preamble=r'\usepackage{xcolor}'
(EDIT: in ooposed to what I previously wrote,there is no need to define in addition imgmath_latex="/usr/local/texlive/2017/bin/x86_64-darwin/latex" thanks jfbu again)
In the .rst file where I have the latex expression, I have
Let :math:`\color{red}x_{1}` be a binary variable.
In the terminal I run
make clean html
("make clean" is the sphinx's best friend)
And its working! wohoo!
I am currently attempting to use the go_remote_library target??, package??, plugin?? in Pants. Real simple question, here:
If in my code I have the import listed as:
import(
"github.com/golang/groupcache"
)
is it valid for me to specify a name of simply "groupcache" instead of the full import path? Here is what my BUILD file looks like:
go_remote_library(name="groupcache",
rev="d781998583680cda80cf61e0b37dd0cd8da2eb52"
)
Am I doing this right? As a side note, is there a Pants target that I can use to test that my BUILD file is valid? Thanks!
You are doing it right. All of the go targets - go_remote_library in this case, but also go_library and go_binary - currently take a name parameter and it must be the name of the directory the BUILD file lives in. The next release of pants (0.0.44) should remove the name parameter taking the choice away from you.
The 1st line of defense is the BUILD Dictionary.
For go_remote_library you'll find this doc.
As to testing, the simplest test is checking syntax, and for that this does the trick:
./pants list path/to/BUILD:
Note the trailing colon attached to the path
This says "List all the targets defined in path/to/BUILD. Here the : means all - its equivalent to the * wildcard in bourne shells for pants targets in BUILD files.
If you want to check more targets all at once you could say:
./pants list ::
Here the recursive glob is used - equivalent to ** in zsh, and so this asks pants to list all the targets in the repo.
If the syntax checks out, you may still have more subtle issues, like defining a go_remote_library that does not point to a valid github project. These issues will only show up when you try to do more than act on the target's metadata like list and depmap goals do. For a go_remote_library, the simplest way to exercise it is to try and resolve the library:
./pants resolve 3rdparty/go/github.com/bitly/go-simplejson2
If you have this BUILD file contents at that path:
go_remote_library(name='go-simplejson2')
Running the resolve will fail since no such github repo exists.
You can do a similar higher-level check with go_library and go_binary targets, instead running ./pants compile .... This will smoke out whether you're missing any required go_remote_library BUILD files or dependencies.
What is the best/correct practice to specify version within your source code tree?
What I want is, for instance, to put VERSION file in the top level of the source tree and get the "version" function to read it.
There is a version section in the cabal file. Is it possible to read it from my source by "help" or "version" functions?
What is the correct practice of specifying the version in one place and making it available globaly?
P.S. Are there any functions in the Cabal library that allow you to pull any section from the cabal file and present it in your source? Then I could simply pull the version section from the cabal file.
-- UPDATE --
Thank you Thomas for an nice piece of knowledge about the Pathes_x module.
Just wanted to add that, apparently, I don't need to put anything into my cabal file. Everything just works without it. All I needed was to import the Pathes_X as you sugested.
Also, I needed to import Data.Version to get the showVersion function to properly format/print the Version data type. So at the end I get something like this:
import Paths_kvman
import Data.Version
runVersion _ = putStrLn ("Version: " ++ (showVersion version))
Now, all I need is to change the version number in the cabal file to propagade it all over my source. Exactly what I needed. Thanks.
Cabal automatically generates a module for each package named Paths_packagename. Just import this package and look at the version value it exports.
Edit: For example:
module Data.Blah where
import Paths_t
func :: IO ()
func = print version
And an example run:
> func
Version {versionBranch = [0,1], versionTags = []}
Be sure to put Paths_packagename in your Other-Modules section of the cabal file.
Best practice is to put the version number in your cabal file, as you have already noted.
I am not aware of any good practices by which you can maintain a single point of truth about the version, yet make the number available both to cabal and to your application.
I would recommend a single file Version.hs in the sources with these contents:
module Version
where
version :: String
version = "3.14159"
You could then, if you wished, use some kind of script to update the cabal file with this number, but I don't know how to do this from within cabal itself.
This strategy will work only for application packages; if you are building a library, you'll need to give some thought to where in the namespace of hierarchical modules your Version.hs will go.
On the whole, I suspect the game is not worth the candle.
P.S. The version number should be immutable, so you want a value, not a function.