The problem I’m having is after the profiles.yml All checks passed! (the connection successful)
when i run dbt get this message
Configuration paths exist in your dbt_project.yml file which do not apply to any resources. There are 1 unused configuration paths:- models.dbt_project.example
when I run
dbt --version
Core: - installed: 1.4.1
- latest: 1.4.1 - Up to date!
Plugins: - sqlserver: 1.3.0 - Not compatible!
- synapse: 1.3.2 - Not compatible!
At least one plugin is out of date or incompatible with dbt-core.
You can find instructions for upgrading here:
https://docs.getdbt.com/docs/installation
The error message is telling you what is wrong. There is config in your dbt_project.yml file that does not apply to any files in your models directory.
When you run dbt init, it creates some example models (.sql files) in the models/example directory, like my_first_dbt_model.sql. It also adds some example config to dbt_project.yml that looks like this:
# towards the bottom...
models:
your_project_name:
# Config indicated by + and applies to all files under models/example/
example:
+materialized: view
You need to delete the example key, since you deleted that directory. You could also delete the keys above it, or keep them, since you'll probably add config at some point.
The OTHER error is probably because you installed dbt-core separately from dbt-synapse. You should delete your virtual environment and start over by just running pip install dbt-synapse, which will automatically install a compatible version of dbt-core. You should NEVER pin versions of dbt-core, only the version of your adapter (since the adapter will specify its compatible versions of dbt-core).
Related
I am attempting to get the volar vue language server to work in place of vetur for neovim's native lsp.
Using both lspconfig and lspinstall I was able to create a working custom install for sumneko_lua (unrelated but had to manually build due to some issues with the built-in :LspInstall lua). Below is that code duplicated and modified for an attempt at using this new vue server:
local vue_config = require'lspinstall/util'.extract_config('vuels')
vue_config.default_config.cmd = {'node', './node_modules/vscode-vue-languageservice/out/index.js', '--stdio'}
require'lspinstall/servers'.newvue = vim.tbl_extend('error', vue_config, {
install_script = [[
! test -f package.json && npm init -y --scope=lspinstall || true
npm install vscode-vue-languageservice#latest
]],
uninstall_script = nil
})
Running :LspInstall newvue installs properly, however :LspInfo shows this language server is attached to the buffer (of a .vue file) but not active. I believe the issue is with this path: ./node_modules/vscode-vue-languageservice/out/index.js. It exists, but may not be the correct entry point? The default vue ls simply has vls as the command because it provides a binary. Am I missing something in this package? I have yet to come across another language server without a single binary to pick out.
Thanks!
Can you try an absolute path to the out.js file? In my pretty elaborate config for a custom Volar install I'm using something just /home/myuser/dev/volar/packages/server/out/index.js (where the volar folder is just the whole volar cloned github repo). My full config is here
I don't think you can use relative paths like you did. I know you're assuming that the "./node_modules" means "workspace directory" but it's hard to tell in which directory nvim-lspconfig opens up those executables.
I have yet to come across another language server without a single binary to pick out.
Volar also provides a binary, it's volar-server (after running npm i -g #volar/server), it's just with a custom install (ie. alongside the real volar) you can't use it, because I assume you want to use your local install with custom code.
As for more indepth debugging/logging, you can check ~/.cache/nvim/lsp.log to see why the language server dies in detail.
When using snakemake wrappers with snakemake version 5.5.2 like this:
rule bcf_to_vcf:
input:
"{prefix}.bcf"
output:
"{prefix}.vcf"
params:
"" # optional parameters for bcftools view (except -o)
wrapper:
"0.38.1/bio/bcftools/view"
I get the following error:
Building DAG of jobs...
WorkflowError:
Failed to open environment file https://bitbucket.org/snakemake/snakemake-wrappers/raw/0.38.1/bio/bcftools/view/environment.yaml:
HTTPError: HTTP Error 404: Not Found
Apparently, the wrapper files are no longer available on bitbucket.
TL/DR:
To use snakemake-wrappers version 0.38.1 and above, you need to use snakemake version 5.7.0 or higher.
What is going on:
Snakemake (and snakemake-wrappers) recently migrated from bitbucket to Github. This causes some minor inconvenience with the paths to the snakemake-wrappers repository used internally by snakemake. The easiest way to solve this is to update snakemake to version 5.7.0 or newer. These version already use the new paths to the Github version.
While the bitbucket repo of snakemake wrappers is still online, it only contains the snakemake-wrapper versions 0.38.0 and lower. To use a higher version of snakemake-wrappers (as 0.38.1 in the code above), you need a newer version of snakemake, which pulls workflow data from the Github version of snakemake-wrappers repo.
I have a bundled application say XYZ-1.0.0.1.exe, with applications A-2.2.0.1.exe and B-1.2.0.1.exe bundled in it. So when we install XYZ, we get A and B as well listed in Add Remove Programs. But when I upgrade XYZ-1.0.0.1 with XYZ-1.0.0.2, which has A-2.2.0.1.exe and B-1.2.0.2.exe, so that A is same and already installed and B needs upgrade. I actually skipped the installation of A by making the install condition false, since the same version is already installed and installed only B while upgrading.
After successfully upgrading I am not able to uninstall the application XYZ, it says some package error, also this happens only if the source file used for upgrading is removed from machine.Actually while uninstalling package has to be referred from program cache, I think since we skipped A package cache has problem.
The error that i get is as follows "Prompt for source of container: WixAttachedContainer, path: C:\Users\ABC\Desktop\XYZ-1.0.0.2.exe Failed to resolve source for file: C:\Users\ABC\Desktop\XYZ-1.0.0.2.exe, error: 0x80070002. Error 0x80070002: Failed while prompting for source (original path 'C:\Users\ABC\Desktop\XYZ-1.0.0.2.exe'). Failed to acquire container: WixAttachedContainer to working path: C:\Users\ABC\AppData\Local\Temp{b4a1c780-306c-40f0-83ad7}, error: 0x80070002. "
This error occurs only when i copy XYZ.exe to any path say desktop and after installation(skip installing A or B since same version of A or B bundled is already installed) and delete the setup file XYZ.exe from saved path ie here Desktop. I am not able to uninstall unless i uninstall A or B which was skipped independently.
Also there is another scenario.
I have a bundled application say XYZ-1.0.0.1.exe, with applications A-2.2.0.1.exe and B-1.2.0.1.exe bundled in it. XYZ-1.0.0.2.exe, which has A-2.2.0.1.exe and B-1.2.0.2.exe. Thes in both versions of XYZ we have the same version of A. When i install XYZ-1.0.0.1.exe i skipped the installation of A-2.2.0.1.exe by setting the install condition to false. So XYZ-1.0.0.1.exe is installed and B-1.2.0.1 is also installed. Further when i upgraded to XYZ-1.0.0.2, I need to install all of the A and B. Installation was successfull and now i have XYZ-1.0.0.2, A-2.2.0.1 and B-1.2.0.2. Now if i delete the installation file of XYZ-1.0.0.2.exe from original path and try to uninstall it breaks.
Initially i thought that the package cache issue arises since A-2.2.0.1.exe was not installed along with XYZ-1.0.0.2.exe since i skipped it as it is already available. But after the second scenario got to know that skipping was not the issue. Since in second scenario A-2.2.0.1.exe was installed along with XYZ-1.0.0.2.exe.
The same issue took huge amount of my time as well. Solved it using a work around. Since the issue is "Prompt for source of container: WixAttachedContainer, path: ", You can copy the exe file XYZ-1.0.0.2 while upgrading to program data or some other path with a default name xyz.exe. At first register for ResolveSource event,then add the following code.Assume the copied exe path is c:/XYZ/xyz.exe
private void OnResolveSource(object sender, ResolveSourceEventArgs e)
{
Application.Engine.SetLocalSource(e.PackageOrContainerId, e.PayloadId, "c:/XYZ/xyz.exe");
e.Result = Result.Retry;
}
If anybody know a better answer, please help.
When setting advanced properties on a program/link to start as another user it is throwing the error:
Sorry - Plasma
KDEInit could not launch 'kdesu':
Could not open library 'libkdeinit5_kdesu'.
Cannot load library /run/current-system/sw/lib/libkdeinit5_kdesu: (/run/current-system/sw/lib/libkdeinit5_kdesu.so: cannot open shared object file: No such file or directory)
I tried to install kdesu using:
[root#nixos:~]# nix-env -qaP kdesu
nixos.kdeFrameworks.kdesu kdesu-5.36.0
[root#nixos:~]# nix-env -iA nixos.kdeFrameworks.kdesu
replacing old ‘kdesu-5.36.0’
installing ‘kdesu-5.36.0’
building path(s) ‘/nix/store/2bn27h5drw0800gk5z2rmwfx78gqbbdc-user-environment’
created 2209 symlinks in user environment
[root#nixos:~]# kdesu
bash: kdesu: command not found
[root#nixos:~]# which kdesu
which: no kdesu in (/root/bin:/run/wrappers/bin:/etc/per-user-pkgs/root/bin:/root/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin)
I also tried installing nix-env -iA nixos.kde-cli-tools but that does not work either.
Any suggestions on how to get kdesu installed on NixOS?
As a general rule, unlike many distros on NixOS installing a library directly doesn't work as intended; the application that needs the library won't be able to find it. Instead, the package must declare all it's dependencies.
Packages which have optional dependencies tend to have a way to add them via configuration. You may want to try something like this in /etc/nixos/configuration.nix
services.xserver.desktopManager.plasma5.extraPackages = with kdeFrameworks;
[ kdesu
];
I'm glad to see that you filed an issue on Nixpkgs, because this is not a configuration issue but a packaging bug.
It looks like kdesu lives in some libexec dir that doesn't hasn't been added to your PATH. It belongs to the kde-cli-tools package. You can run it with
$(nix-build '<nixpkgs>' -A kde-cli-tools --no-out-link)/lib/libexec/kf5/kdesu
You can use the above as an alias to launch kdesu until the fix to the packaging bug arrives.
I updated the SQL file for my module - how do i get it to automatically run again without creating a new version of it?
I am working on my first module and just need to tweak this one so it works on a new install for someone else.
When Magento automatically runs a SQL file for a setup resource, it makes an entry in the core_resource table.
mysql> SELECT code,version,data_version FROM core_resource;
adminnotification_setup 1.0.0 1.0.0
admin_setup 0.7.2 0.7.2
amazonpayments_setup 0.1.2 0.1.2
api_setup 0.8.1 0.8.1
backup_setup 0.7.0 0.7.0
bundle_setup 0.1.11 0.1.11
...
You'll need to remove the single row in this table that corresponds to your module, and then clear your Magento cache. This will let you re-run your setup resource SQL file.
ONLY remove that single row — if you remove rows for the core modules, there will be much breaking and weeping.