I'd like to avoid always adding --scala-platform-version=2.11 to ./pants. Can I make this the default with configuration in pants.ini?
It turns out that pants options live under scopes, so I needed to have:
[scala-platform]
version: 2.11
in my pants.ini file.
Add
[scala]
version: 2.12
to yours pants.ini
from official pants repo example
Related
I was just using typeorm with NestJS as usual. But it installed version 8.1.4 instead of my previously used 8.0.3. With the newer version I couldn't get the ormconfig.json working. I then checked and installed 8.0.3 and it worked again.
I have also tried with 9.0.0 and I couldn't get it to work their either.
Does somebody else has the same issue and maybe a temporary fix?
Thanks!
With #nestjs/typeorm#8.1.0 and on typeorm#^.3.0 is used, which doesn't use the ormconfig.json. You'd need to update your code to make the ormconfig work (i.e. get rid of it and follow the 0.3.0 format).
I'm trying to use the librarian-puppet to fetch forge modules from an Artifactory repository.
In my Puppetfile I have something like:
forge "https://<artifactory_host>/artifactory/api/puppet/<repo_key>" #From artifactory docs
# PuppetLabs Modules
mod 'puppetlabs/stdlib', '4.24.0'
The command that I'm using is /usr/local/bin/pdk bundle -- exec librarian-puppet install --no-use-v1-api --verbose
The error that I get is:
[Librarian] Resolving puppetlabs-stdlib (= 4.24.0) <https://<artifactory_host>/artifactory/api/puppet/<repo_key>>
[Librarian] Checking manifests Unable to find module 'puppetlabs-stdlib' on https://<artifactory_host>/artifactory/api/puppet/<repo_key>
/tmp/tmp.BXyhBoNRiR/.pdk/cache/ruby/2.1.0/gems/librarian-puppet-3.0.0/lib/librarian/puppet/source/forge/repo_v3.rb:44:in `rescue in get_module'
/tmp/tmp.BXyhBoNRiR/.pdk/cache/ruby/2.1.0/gems/librarian-puppet-3.0.0/lib/librarian/puppet/source/forge/repo_v3.rb:41:in `get_module'
Versions:
puppet 3.8.7
pdk 1.5.0
ruby 2.1.9
According to the documentation at https://www.jfrog.com/confluence/display/RTF/Puppet+Repositories#PuppetRepositories-Usinglibrarian-puppet, it seems I'm trying to get the modules correctly using the librarian-puppet, but something most be missing.
Thanks for any help.
I think Artifacotry does not support Puppet 3.8.7 its documented in Wiki.
Puppet version support
Puppet does not support a context path up to version 4.9.1, we recommend using Artifactory with Puppet version 4.9.2 and above. Please see below if you are using Puppet 4.9.1 and below.
The official Artifactory documentation (not a wiki) recommends using Puppet 4.9.2 or later with Artifactory:
Puppet version support
Puppet does not support a context path up to version 4.9.1, we
recommend using Artifactory with Puppet version 4.9.2 and above.
Please see below if you are using Puppet 4.9.1 and below.
(Emphasis in the original.)
As that comment indicates, however, the docs do also suggest a workaround for use with earlier Puppet:
If you need to use Puppet 4.9.1 and below you can use a workaround
which uses NGINX or Apache to rewrite all requests from /v3/* to
/artifactory/api/puppet/<repo-name>/v3/*.
The docs go on to present some example configurations, which I will not repeat here.
I am working on a nodejs project with typescript 2.2 that is using node 6.3.1 and I want to migrate from using typings to using #types. By doing so I ran into a set of questions related to whether there is a relationship between the version of the #types file and the corresponding npm package.
If I use jasmine as an example, the existing versions of the types definitions are
npm show #types/jasmine#* version
#types/jasmine#1.3.0 '1.3.0'
#types/jasmine#1.3.1 '1.3.1'
#types/jasmine#1.3.2 '1.3.2'
#types/jasmine#2.2.29 '2.2.29'
#types/jasmine#2.2.30 '2.2.30'
#types/jasmine#2.2.31 '2.2.31'
#types/jasmine#2.2.32 '2.2.32'
#types/jasmine#2.2.33 '2.2.33'
#types/jasmine#2.2.34 '2.2.34'
#types/jasmine#2.5.35 '2.5.35'
#types/jasmine#2.5.36 '2.5.36'
#types/jasmine#2.5.37 '2.5.37'
#types/jasmine#2.5.38 '2.5.38'
#types/jasmine#2.5.39 '2.5.39'
#types/jasmine#2.5.40 '2.5.40'
#types/jasmine#2.5.41 '2.5.41'
#types/jasmine#2.5.42 '2.5.42'
#types/jasmine#2.5.43 '2.5.43'
#types/jasmine#2.5.44 '2.5.44'
#types/jasmine#2.5.45 '2.5.45'
#types/jasmine#2.5.46 '2.5.46'
But if I examine the versions of the jasmine packages I have;
npm show jasmine#* version
jasmine#2.0.1 '2.0.1'
jasmine#2.1.0 '2.1.0'
jasmine#2.1.1 '2.1.1'
jasmine#2.2.0 '2.2.0'
jasmine#2.2.1 '2.2.1'
jasmine#2.3.0 '2.3.0'
jasmine#2.3.1 '2.3.1'
jasmine#2.3.2 '2.3.2'
jasmine#2.4.0 '2.4.0'
jasmine#2.4.1 '2.4.1'
jasmine#2.5.0 '2.5.0'
jasmine#2.5.1 '2.5.1'
jasmine#2.5.2 '2.5.2'
jasmine#2.5.3 '2.5.3'
Let’s say I am using version 2.4.0 of jasmine, which version of #types/jasmine should I pick? Because even if I use the latest of both, 2.5.46 does not match with 2.5.3.
Another example would be node itself, there are basically 6.0 or 7.0 versions in #types, and typings has only the ones shown below, being 6.0 reported as obsolete. So, what version of node are those typings actually tied to?
typings view dt~node --versions
TAG VERSION DESCRIPTION COMPILER LOCATION
UPDATED
7.0.0+20170322231424 7.0.0 github:DefinitelyTyped/DefinitelyTyped/node/index.d.ts#a4a912a0cd1849fa7df0e5d909c8625fba04e49d 2017-03-22T23:14:24.000Z
6.0.0+20161121110008 6.0.0 github:DefinitelyTyped/DefinitelyTyped/node/node.d.ts#fb7fbd28b477f5e239467e69397ed020d92817e7 2016-11-21T11:00:08.000Z
Thanks
The major and minor versions of the DefinitelyTyped packages are supposed to correspond to the major and minor versions of the package they are types for. The patch version increments whenever the .d.ts file changes for other reasons. Because the minor version shouldn't represent breaking changes, in theory, you can use the highest 2.x.y definition file available for a 2.a.b.c library.
But now the caveats begin.
The header in the definition file may not have changed at the right time
Library authors do not necessarily follow semver*
The definition file may not be 100% correct at any given point, in either direction (i.e. listing a 2.6 feature under a 2.5 version, or failing to list a 2.4 in function in the 2.5 file)
* In fact, no one does
A detailed explanation can be found in official docs FAQ: How do Definitely Typed package versions relate to versions of the corresponding library?
I am adding a dependency Package, and I am getting this error at build time:
error: NoSources("[...]/Tests/TestResources")
Please tell me how to get past this error. Is there a way to instruct SPM not to go into the Tests for a specific dependency? A package-specific exclude: [] statement or something.
$ swift --version
Swift version 3.0-dev (LLVM b361b0fc05, Clang 11493b0f62, Swift 24a0c3de75)
Target: x86_64-unknown-linux-gnu
Thank you!
You have exclude directive in Package.swift - https://github.com/apple/swift-package-manager/blob/master/Documentation/Package.swift.md
It seems you are using the snapshot of swift of March 1st, there is a defect in this version regarding excluding files in Tests https://bugs.swift.org/browse/SR-864. It is solved in the later versions, so you can switch to a newer version, the last one is of 24-th of March.
As a temporarily workaround, if you still want to use your current version of swift, you can just move TestResources out of Test directory.
I've seen the following issue mentioned in another thread a few days ago amongst other problems, but the solution for this issue (to me) didn't seem to be addressed.
I recently ran a test on my Ruby 1.9.2-p290 environment and was presented with the following error when I ran a test script:
You are using an old or stdlib version of json gem
Please upgrade to the recent version by adding this to your Gemfile:
gem 'json', '~> 1.7.7'
This issue continued when I created a completely fresh Ruby 1.9.3-p392 environment, running on Windows XP (don't ask). What confuses me is that even when I have json 1.7.7 or 1.8.0 installed (gem list is pasted below), I still get this message when I run my test. It's not really affecting my test results, but the warning is just rather annoying to see each time.
Which Gemfile do I need to add this version into, and where would it be located?
gem list:
bigdecimal (1.1.0)
childprocess (0.3.9)
commonwatir (4.0.0)
ffi (1.8.1 x86-mingw32)
io-console (0.4.2, 0.3)
json (1.8.0, 1.7.7, 1.5.5)
mini_portile (0.5.0)
minitest (5.0.0, 2.5.1)
multi_json (1.7.3)
rake (10.1.0.beta.3, 10.0.4, 0.9.2.2)
rdoc (4.0.1, 3.9.5)
rubygems-update (2.0.3)
rubyzip (0.9.9)
selenium-webdriver (2.32.1)
watir-webdriver (0.6.4)
websocket (1.0.7)
win32-api (1.4.8 x86-mingw32)
win32-process (0.7.2)
windows-api (0.4.2)
windows-pr (1.2.2)
The message is coming from the multi_json gem, and it seems like it could be a bug. I suggest keeping an eye on this GitHub ticket.
If the message is too distressing, you can downgrade multi_json to version 1.6.1 to get rid of it. (At least this works for me.)
UPDATE:
It looks to me like the root of the problem is that while multi_json wants to limit its use of the json and json_pure gems to specific versions, the author of multi_json isn't using the gem method in his code to activate these versions. (It sounds like he thinks Bundler is the only way to specify versions of gems; it isn't.)
Since multi_json will try the oj and yajl-ruby gems before it tries json, using one of those may be the best workaround of all. So you can just install the latest multi_json and then install either oj or yajl-ruby along with it.
Try this:
gem update --system
gem update
Go to your Ruby installation path, for example,
C:\Ruby192\lib\ruby\1.9.1\json
Open version.rb file and update the version detail as shown bellow:
VERSION = '1.7.7'
Try running your tests with the bundle exec command. This will force your environment to use the gems in Gemfile.lock.