How to use relative path to packages in JSonTransform config file - json

My team uses a shared Git repo that contains, in addition to a src folder with a .net solution, also a tools folder containing JSonTransform tool, that we use during deploy to generate config production files.
This tool uses a json config file named JsonTransform.runtimeconfig.dev.json, with this content:
{
"runtimeOptions": {
"additionalProbingPaths": [
"C:\\Users\\**specific_username**\\.dotnet\\store\\|arch|\\|tfm|",
"C:\\Users\\**specific_username**\\.nuget\\packages",
"C:\\Program Files\\dotnet\\sdk\\NuGetFallbackFolder"
]
}
}
These paths are used when resolving nuget package dependencies by JSonTransform. As you can see, the first two can only work on a specific machine, since they are absolute path containing a "specific_username".
There is a way to use relative paths to .dotnet and .nuget folders, so that it can works on every pc?

Related

Can I use opam to make a package out of a local file and install it?

I'm new to opam and trying to figure out how to use it properly. For a class, I want to set up students with an environment that has some custom packages installed. (The package will consist of some raw .ml files that I got from a colleague at another school; the files are on their github but there's no .opam file that I can see, and as far as I know they're not in any official package release.)
Can I somehow call these local .ml files a package and ask opam to install it? Do the files have to be on github first, and if so can I use my colleague's existing repository as the source? I don't want to make any of this public, since it is not my own work; I just want to configure my local environment so that the code in the files can be included easily as a package. Basically I don't know the best way to proceed so I'm happy for any advice.
You can add a custom opam file in the base directory of the project. See the documentation for how to create that file.
Then you can enter opam pin add . in the base directory and your project will be installed as if it was an opam package. Check opam pin --help for more info (you can also pin to a remote git project for instance).
Note that though the default repository is hosted on github, this is in no way a requirement for opam. Opam is dependent on git but you can absolutely use it with a private git repository. If you want to use your colleague's repository as the source, that is totally doable though it is often preferable to have the opam file at the root of the directory (you can do a PR on their repository or make your own fork of it on github, the site makes it clear you copied the code).
If pinning is not to your taste, you can also create your own repository though this is probably a bit too heavyweight for your needs.
Good luck!

which files are the ones I should upload to a host

I learned to do a working environment based bower, from there install yoeman and gulp and materialize, I made a web page to root of all this, now I want to upload a host (like 000webhost or firebase) but I do not know which files are the ones I should upload
thx
You should upload everything except bower_components directory since it's content is used only when you compile down the things using gulp on your local machine. Once all your source files are piped through gulp, they are not required on the destination location. None of those files is or should be used during a http request.
I don't know exactly what is your project's structure, but because you specified what you use (bower, gulp) then I can deduct.
So after gulp finishes it's work, you have a public directory where all your combined, minified and copied assets live. This is obviously needed on the server, in your markup, you should refer to those files, not the ones fetched by bower when you've done bower install library1 --save. bower install library2 --save.

How to build documentations project placed outside of docs directory using ReadTheDocs?

I am generating documentation project using ReadThedocs (mkdocs). But It's generating documentation project for the .md files which are placed in docs directory. My requirement is, I want to build documentation project for every .md file placed anywhere in the github repository.
How to achieve this?
You need to specify in the Mkdocs configuration (mkdocs.yml) the location of your documentation directory to be the current directory '.'.
Example:
site_name: My Documentation Project
docs_dir: '.'
By default, the Mkdocs looks in a subdirectory of your project labled docs:
docs_dir
Lets you set the directory containing the documentation source markdown files. This can either be a relative directory, in which case it is resolved relative to the directory containing you configuration file, or it can be an absolute directory path.
default: 'docs'
This is not possible in MkDocs by default. See this GitHub issue thread for rationale. There is however a plugin called mkdocs-same-dir that can be used to achieve this.

SSIS Deployment Woes

I'm quite confused as to how to create a deployment in SSIS 2008 that I can use throughout the various sites we are going to deploy to. I'm using the deployment utility to deploy my ETL packages which are file based and executed using a SQL job.
When I rebuild my solution, the deployment files are created along with their configuration files which I bind my connection strings to. I've discovered that each of the packages are still referencing the configuration files in my project folder, rather than the configuration files in the deployment folder. I thought that when I created a deployment, the paths referencing the configuration files would be relative paths.
Ideally, what I would have liked to have been able to do would be to copy the contents of the deployment folder to a flash drive, plug it in at the site I'm deploying to and edit the configuration file per the customer site, execute the deployment manifest file in the folder and expect everything to work. But this doesn't seem to be the case.
I also notice that the SQL job has an option to specify the configuration files for the packages, but this doesn't seem to have an effect either. I must clearly be doing something wrong here, please could someone assist.
Seems like you are encountering these two issues with SSIS deployment and execution:
Configuration file references are stored with absolute paths (meaning the concrete path used in the development environment when the configuration file reference was created, and in production this is the same path that will be used).
Specifying a different configuration file at runtime in SSIS 2008 cannot override values specified at design time (see Understanding How SSIS Package Configurations Are Applied at Run Time).
To deploy your packages with a simple file copy the way you describe, you must change your packages to use a relative reference to your configuration files:
Right click the package file and select View Source to open the XML view of the package source. Search for your configuration file, which will include the path, and remove the path; keeping only the filename portion. Alternatively, change the absolute path to a relative path to the configuration file. Save and close the XML view of the package.
Now when you deploy the package and the configuration file together, ensuring they have the same relative location to each other, the package will find the config file by the relative path, and work the way you expect.
Note: from this point forward you will need to open the BIDS IDE by double-clicking on the project or solution file. If you launch Visual Studio, and then open the project or solution from within the IDE, the IDE will not be able to find the configuration file when you execute the package (the current directory will be Windows\System32, not your package folder).

Tidying up folder structure for libraries added with composer

Starting with a default installation of SilverStripe (using composer), I have the folders framework, cms, mysite, etc.
Using composer I then added some additional code, such as userforms with the command:
composer require silverstripe/userforms
This created the folder userforms in the root of my site.
However, to manage my code more easily, it would be nicer if all modules added by composer were in a subfolder together. This answer indicates how a default vendor-dir directory can be specified using the composer.json file.
There is already a vendor folder in existence (if I understand correctly, this is used by composer). Is it ok to use the vendor folder as the default vendor-dir setting, or would it be better to create a new folder instead?
Also, what do I need to do to move existing folders (such as userforms) into the appropriate sub-folder?
This behaviour is specified by type. The packages with "type": "library" will be placed into vendor folder.
This is how the framework was designed, it expects the files to be located where they are now. It uses legacy code and is unable to make use of Composer autoloading.