I searched for [rust] "instead of a package manifest" on this site before asking and found no hits. I also read about virtual manifests here but did not resolve my question.
My goal is to make changes to azul.
To achieve this I read about patching dependencies here, and now I have this Cargo.toml
[package]
name = "my_first_azul_app"
version = "0.1.0"
authors = ["Name <Email>"]
edition = "2018"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
azul = { git = "https://github.com/maps4print/azul" }
[patch."https://github.com/maps4print/azul"]
azul = { path = "../azul" }
In path ../azul I have checked out the azul project with git clone. In main.rs I have followed this to get,
extern crate azul;
fn main() {
println!("Hello world!");
}
Then I try to test
$ cargo run
error: failed to resolve patches for `https://github.com/maps4print/azul`
Caused by:
failed to load source for a dependency on `azul`
Caused by:
Unable to update /home/name/projects/azul
Caused by:
found a virtual manifest at `/home/name/projects/azul/Cargo.toml` instead of a package manifest
I do not understand the final caused by line.
If I remove the [patch] configuration, it "works".
Quoting because it fails to compile, but that is why I am trying to check it out and attempt a fix. What charges do I need to make to develop the azul dependency?
TIA,
looks like azul is using workspaces so if you want to refer to it via path you must point to the exact member(s) of that workspace.
azul's Cargo.toml contains
[workspace]
members = [
"cargo/azul",
"cargo/azul-css",
"cargo/azul-core",
"cargo/azul-layout",
"cargo/azul-text-layout",
"cargo/azul-widgets",
"cargo/azul-css-parser",
"cargo/azul-native-style",
]
so I believe you should be able to do something like:
[dependencies]
azul = { path = "../azul/cargo/azul"
azul-css = { path = "../azul/cargo/azul-css" }
you may need all/some of the members there.
Related
I tried to do a hello world with material-yew.
I tried to add this use declaration according to Material Yew's home page.
use material_yew::MatButton;
I've also tried this version that I've also seen in the docs:
use material_yew::button::MatButton;
But both of them give a similar error:
error[E0432]: unresolved import material_yew::MatButton
I have these in my Cargo.toml:
[dependencies]
yew = "0.19.3"
material-yew = "0.2.0"
And I'm using trunk serve to run the app.
You need to enable the button feature (or the full feature that implies it):
material-yew = { version = "0.2.0", features = ["button"] }
I have been working on Terraform using AzureDevOps before that I developed tf files using VS code and everything worked fine when try to move files from VS code to Azure DevOps , getting issue on Archive source file path it unable to find the directory, searched every where but unable to resolve this,
Path which was working fine on VS code was “…/Folder name” using same path in Azure DevOps as I have upload completed folder that I have build in VS code but it always get failed when try to archive files as it un-able to find the directory.
[Code Block DevOps]
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
# Root module should specify the maximum provider version
# The ~> operator is a convenient shorthand for allowing only patch releases within a specific minor release.
version = "~>2.11"
}
}
}
provider "azurerm" {
features {}
#skip_provider_registration = true
}
locals {
location = "uksouth"
}
data "archive_file" "file_function_app" {
type = "zip"
source_dir = "../BlobToBlobTransferPackage"
output_path = "blobtoblobtransfer-app.zip"
}
module "windows_consumption" {
source = "./modules/fa"
archive_file = data.archive_file.file_function_app
}
output "windows_consumption_hostname" {
value = module.windows_consumption.function_app_default_hostname
}
Image of VS Code where everything is working fine:
Image of DevOps where getting Missing Directory Error:
Folder Structure that is working fine with VS code
It was due to path which is fixed now,
I'm trying to run a pitest report on a gradle + kotlin project, but I get the following error:
Exception in thread "main" org.pitest.help.PitHelpError: No mutations found. This probably means there is an issue with either the supplied classpath or filters.
See http://pitest.org for more details.
at org.pitest.mutationtest.tooling.MutationCoverage.checkMutationsFound(MutationCoverage.java:352)
at org.pitest.mutationtest.tooling.MutationCoverage.runReport(MutationCoverage.java:132)
at org.pitest.mutationtest.tooling.EntryPoint.execute(EntryPoint.java:123)
at org.pitest.mutationtest.tooling.EntryPoint.execute(EntryPoint.java:54)
at org.pitest.mutationtest.commandline.MutationCoverageReport.runReport(MutationCoverageReport.java:98)
at org.pitest.mutationtest.commandline.MutationCoverageReport.main(MutationCoverageReport.java:45)
I tried everything that I found on google but still not working for me:
This is my build.gradle config
plugins {
id 'groovy-gradle-plugin'
id 'info.solidsoft.pitest' version '1.7.4'
}
repositories {
maven { url "https://plugins.gradle.org/m2/" }
gradlePluginPortal()
}
dependencies {
implementation 'org.jetbrains.kotlin:kotlin-gradle-plugin:1.4.20'
implementation 'com.github.jengelman.gradle.plugins:shadow:6.1.0'
}
pitest {
targetClasses = ['com.project.root.to.test.with.pitest.src*'] //by default
"${project.group}.*"
pitestVersion = '1.7.4' //not needed when a default PIT version should be used
threads = 4
outputFormats = ['XML', 'HTML']
timestampedReports = false
}
I tried this targetClasses in a different ways:
targetClasses = ['com.project.root.to.test.with.pitest.src.*'] //by default
targetClasses = ['com/project/root/to/test/with/pitest/src*'] //by default
Can someone help me, please?
You look to be trying to supply pitest with a source folder
com.project.root.to.test.with.pitest.src.
Pitest works against the compiled bytecode, not the source files. It expects
a glob that matches against the package.
com.example.*
I've experienced this same issue today. You'll need to make sure all references to pitest use the same version 1.7.4. This includes
plugin: id 'info.solidsoft.pitest' version '1.7.4'
pitestVersion: pitestVersion.set('1.7.4')
dependency: testCompile
'info.solidsoft.gradle.pitest:gradle-pitest-plugin:1.7.4'
Which out changing all references, then it will break.
Not very experienced with Terraform. I upgraded my project from 12 to 13 and looking to upgrade it to 14 afterwards.
As the documentation specifies, I ran terraform 0.13upgrade and terraform 0.13upgrade module, my directory became like this:
terraform
├── module
│ ├── main.tf
│ └── versions.tf
├── main.tf
└── versions.tf
I moved my versions but the problem is that I specified them only in the root versions.tf:
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = "~> 3.8.0"
}
}
in module/versions.tf I kept only:
terraform {
required_providers {
google = {
source = "hashicorp/google"
}
}
Do child modules inherit the version from the root (where they are imported) or does this mean my module will automatically run with a more recent provider version (3.64 I think)?
Should I simply remove module/versions.tf? (It's tiresome to have 2 versions to edit everytime).
Thanks!
For a given Terraform configuration (which includes both the root module and any other modules you might call), there can be only one version of each provider. Terraform recognizes that two providers are "the same" by them having the same source value after normalization, and in your examples here both are using hashicorp/google, which is short for registry.terraform.io/hashicorp/google, and so both of them need to be able to agree on a particular version of that provider to use.
Terraform handles version constraints from multiple providers by combining them together and trying to honor all of them together. In your examples here you've written no version argument in the child module, and this means "any version is allowed".
Terraform will therefore look for an available provider version that matches both the ~> 3.8.0 constraint and the implied "any version" constraint, and since the ~> 3.8.0 constraint is a proper subset of "any version" it effectively takes priority over the open constraint in the child module. This is not strictly "inheritance", but it happens to behave somewhat like it in this case because the child module is totally unconstrained.
A more interesting example would be if both of your modules specified different version constraints, which means we can see a more interesting effect of combining them. Let's pretend that your two modules had the following requirements instead:
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = "~> 3.8.2"
}
}
}
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = ">= 3.8.5"
}
}
}
In this situation neither of these constraints is a subset of the other, but they do have some overlap: all of the 3.8.x versions from 3.8.5 onwards are acceptable to both modules. Therefore Terraform will select the newest available version from that set.
If you write two modules that have conflicting version constraints then that would be an error:
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = "~> 3.7.0"
}
}
}
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = "~> 3.8.5"
}
}
}
There is no provider version that is both a 3.7.x release and a 3.8.x release at the same time, so no release can ever possibly match both of these constraints, and thus provider version selection will fail. It's for this reason that the Terraform documentation section Best Practices for Provider Versions advises to use ~> version constraints only in the root module.
I'm following this tutorial to publish an example Android Studio library on Jcenter:
http://crushingcode.co/publish-your-android-library-via-jcenter/
It seems very clear.
I've created my GitHub repository with this library at this link:
https://github.com/alessandroargentieri/mylibview
I've also Signed in to Bintray.com, and created a new repository which must contain my library (as explained in the tutorial above).
To publish a repository on Bintray I must create an organisation, then you create the repository. So these are my data:
Bintray username: alessandroargentieri
organisation: alexmawashi
repository: https://bintray.com/alexmawashi/my_android_repository
then, in Android Studio, in the gradle file of my library module, I've this data:
apply plugin: 'com.android.library'
ext {
bintrayRepo = 'my_android_repository' //maven
bintrayName = 'mylibview' // Has to be same as your library module name
publishedGroupId = 'mawashi.alex.mylittlelibrary'
libraryName = 'MyLibView'
artifact = 'mylibview' // Has to be same as your library module name
libraryDescription = 'Android Library to use a custom view'
// Your github repo link
siteUrl = 'https://github.com/alessandroargentieri/mylibview'
gitUrl = 'https://github.com/alessandroargentieri/mylibview.git'
githubRepository= 'alessandroargentieri/mylibview'
libraryVersion = '1.0'
developerId = 'alexmawashi'
developerName = 'Alessandro Argentieri'
developerEmail = 'alexmawashi87#gmail.com'
licenseName = 'The Apache Software License, Version 2.0'
licenseUrl = 'http://www.apache.org/licenses/LICENSE-2.0.txt'
allLicenses = ["Apache-2.0"]
}
...
...
apply from: 'https://raw.githubusercontent.com/nisrulz/JCenter/master/installv1.gradle'
apply from: 'https://raw.githubusercontent.com/nisrulz/JCenter/master/bintrayv1.gradle'
When I use the terminal and write:
gradlew clean build install bintrayUpload --stacktrace
After a few minutes, I get this error:
What went wrong:
Execution failed for task ':mylittlelibrary:bintrayUpload'.
> Could not create package 'alessandroargentieri/my_android_repository/mylibview': HTTP/1.1 404 Not Found [message:Repo 'my_android_repository' was not found]
What am I doing wrong?
Thanks.
There also might be a problem here:
https://raw.githubusercontent.com/nisrulz/JCenter/master/bintrayv1.gradle
If your repo belong to your organisation then you are going to need the userOrg parameter set.
See https://github.com/bintray/gradle-bintray-plugin#step-4-add-your-bintray-package-information-to-the-bintray-closure step 4
Also see: HTTP/1.1 401 Unauthorized when uploading binary on bintray
For this to work properly, your gradle.properties file needs to have a bintray.user and a bintray.apikey (which is your bintray API key) configured (see the include in https://raw.githubusercontent.com/nisrulz/JCenter/master/bintrayv1.gradle )