I've got a number of local stack packages, in the usual form of a directory with a stack.yaml file, and PackageName.cabal, and a src directory.
I'd like to have a local stack packages depend on another local stack package, preferably without this option being carried with the package if I do ever upload it to Hackage (at which point the local package will make no sense).
A directory with symbolic links to all my local stackage packages and a global override to search that directory first will be fine, but also specifying the required local packages on a per package basis is also fine, as long as this configuration options don't get carried alone if I package it up with Hackage.
How can I achieve this? Links to the appropriate section in the stack docs is fine, and perhaps the answer is in there and I just can't find it.
Related
If xdebug provides information about files (e.g. stack traces), we can configure the way it works.
https://xdebug.org/docs/all_settings#filename_format
But on my host machine, the files have a different location, then on my guest machine.
E.g.: /home/me/project/myapp VS /app
Is there any way to configure xdebug so that I can map the files and get the correct host file paths?
There is currently no way to do this with Xdebug.
I have been working on a plan to allow for something like this, but it has not concluded into an actual implementation idea. I would recommend that you file an issue at Xdebug's issue tracker at https://bugs.xdebug.org to register your interest in this feature.
Is is possible to have a workspace (in VSC or any IDE) whereby said local project/folder contains 1 more or more sub folders that are cloud based (such as iCloud)?
I have a standard create react app "project" stored locally on my iMac (home) and when I need to use the same files on my work computer (macbook) I have either committed said changes (SourceTree -> remote) or taken copy via USB). Is there a way to sync just "some" folders to iCloud so that they are available from any location? (and also not break git/sourcetree)
Probable easiest to do the whole folder? and ignore \node_modules (like gitignore, nosync) perhaps?
my-app\
my-app\node_modules <- not this folder
my-app\public
my-app\src
The more I investigate this issue, the more it appears not to be possible in the context above, even using symbolic links and the .nosync file extn. :-(
I am trying to install/add manually the *.jl-master.zip files, I am doing this because I have a computer without access to internet but I don't know how to do the offline installation.
The version of Julia is 1.3.0 and the O.S. Windows 10
I had tried this,
Instruction I followed
but for me It does not work.
Thanks
Regards
Installing Julia packages offline is very difficult due to the fact how binary dependencies work.
You have basically two options:
buying JuliaTeam/JuliaPro from Julia Computing (maybe someone who is using it will ever see that thread and could share their experience?)
hacking
Regarding the second option the best bet is to install all required packages on a different machine having and copy the .julia folder to your offline machine (or, depending on your configuration folder referenced by the JULIA_DEPOT_PATH system environment variable).
However, in most cases you will need to rebuild several packages. The problem is that Julia packages have several binary dependencies that come from different sources. This problem has been noted by the Julia community and is being addressed by the Julia Artifacts mechanism.
Today the most common step is to manually edit deps/build.jl file in each Julia package that is downloading binary resources in its build process and make the build code to point to files in your local repository. Once done you can rebuild the package offline by running using Pkg;Pkg.build("PackageName").
I have a Julia package in my home directory under the name Foo. Foo is a directory with Project.toml file that describes the package dependences, name, etc. I want to be able to use this package from another folder in a particular manner as follows.
Build the package Foo
Register Foo in a local Julia repository
Run Pkg.add("Foo") from anywhere on the system, such as script.jl which would have the following:
using Pkg
Pkg.add("Foo")
using Foo
# Now use Foo
Foo.bar()
Here is what I've tried so far.
Navigate to Baz directory where I want to run Baz/script.jl
Use repl, hit ] and run dev --local PATH_TO_FOO
From repl, run using Foo
Foo is now accessible in the current repl session (or script)
Summary: I have managed to import a package Foo in another directory Baz.
Basically, I want to be able to write a script.jl that can make use of the local registry instead of this dev --local . method.
I assume that this is for personal use and you are not a system administrator for a large group.
Maintaining a registry is hard work. I would avoid creating a registry if at all possible. If your goal is to make the use of scripts less painful, a lighter solution exists: shared environments.
A shared environment is a regular environment, created in a canonical location. This means that Pkg will be able to locate it by name: you do not have to specify an explicit path.
To set up a shared environment:
give it a name: Pkg.activate("ScriptEnvironment"; shared=true)
populate it: Pkg.add(Pkg.PackageSpec(; path="/path/to/Foo")) (depending on your use case, you can also use Pkg.develop, add registered packages, etc)
that's all!
Now all your scripts can use the shared environment:
using Pkg
Pkg.activate("ScriptEnvironment"; shared=true)
using Foo
If other sets of scripts require different sets of packages, repeat the procedure with a different shared name. Pkg environments are really cheap so feel free to make liberal use of this approach.
Note: I would discourage beginning scripts with Pkg.add("Foo") because this carries the risk of inadvertently polluting the active environment.
There are some instructions on registry creation and maintenance at https://github.com/HolyLab/HolyLabRegistry.
I am trying to make our SQL Server Integration Services packages as portable as possible and the one thing that is preventing that is that the path to the config is always an absolute path, which makes testing and deployment a headache. Are there any suggestions for making this more manageble?
Another issue is when another developer gets the package out of source control the path is specific to the developers machine.
If you are trying to execute your packages using Visual Studio then the configuration file path will be hardcoded in there. So if you move your project around you'll need to change the path in the package settings. To avoid this you could use the Environment variable option to store the configuration file path. Then you'll only need to change that.
For testing and deployment however you should probably use the dtexec utility to execute your packages. Make some batch files for that. Preferably one for each different environment. Here the configuration file path can be relative.
dtexec /File Package.dtsx /Conf configuration.dtsConfig
This is if you're packages are on file system. You can also store them in SQL Server. You can also store your configuration in SQL Server which may provide flexibility.
After several hours trying to make this work I found a solution here (not the best one, but it works)
Locate your configuration files (dtsconfig files) in the same directory as your solution file (.sln file)
ALWAYS open your solution by double-clicking the solution file (.sln file). This will set the ‘working folder’ to be where the solution lives, your configuration file will be read correctly
Otherwise the relative paths did not work for me.
Check out the free utility that can edit SSIS configuration file paths without BIDS:
http://ssisconfigeditor.codeplex.com/
My stock standard trick for these sorts of problems are mapping drives.
Either by using a mapped network drive or by using Subst (both methods are interchangable).
e.g. Map the location of your package to N:\ then inside your package use paths using N:\MyParentPackage.dtsx, N:\MyChildPackage.dtsx. The packages can be on totally different drives in different folders on different machines, it'll work once you map the package location to the N:\
I usually put a script along side the project files to map the drive, which maps the drive so it can be easily run before. One gotcha, if you're using subst on VISTA - Win8, map it for elevated and non-elevated.
I use the same approach for file references in Visual Studio projects. Only issue with this approach, you use to solve too many issues in your dev environment and you'll run out of drives letters.