I am trying to install the google benchmark library using the C++ package manager Conan. However, the user and channel fields seem to be missing from the conan-center. I also get an error if I try to search for the library on the conan-center.
$conan search benchmark --remote=conan-center
ERROR: Value provided for user name, '_' (type str), is too short. Valid names must contain at least 2 characters.. [Remote: conan-center]
Is something off with the conan-center, or am I missing something? I noticed that other packages show the same behavior (gtest, doctest, etc.), although they also have a "regular" version provided by bincrafters.
Since Conan 1.18 the package namespace became optional. This feature was introduced together with the new Conan Center Index which has received all Conan recipes again, but without namespace.
All old and new packages, including from Conan Community and Bincrafters, will stay in Bintray Conan Center as well.
Now about your error:
ERROR: Value provided for user name, '_' (type str), is too short. Valid names must contain at least 2 characters.. [Remote: conan-center]
This error occurred because your Conan client is outdated. I believe you are running <= 1.17.
I strongly recommend you update your Conan client to the latest version (1.20.4).
Regards!
Related
This is about the virtualenv-generator of conan:
I have a provider-package that defines environment-variables using self.env_info.
This means that when doing conan install in my consumer-package, i receive a convenient activate.sh script that sets up my virtual environment.
However i would like to add some environment-variables to this virtual environment from my consumer.
Of course i could just add these manually, or write a simple wrapper-script that uses the environment-variables from my provider and adds a few itself.
This means creating custom solutions though, and i would like to only use conan for these things wherever possible.
Basically, i want my consumer-provided environment-variables to land inside environment.sh.env as soon as i execute conan install.
An acceptable alternative would be if they landed there when i execute conan build
One thing i've tried:
def requirements(self):
self.env_info.FOO = "bar"
But, as described in the docs self.env_info is only defined inside the package_infomethod.
Is there the possibility within conan of extending the environment-variables of a provider-package from a consumer-package?
You can use a special option which can support anything: ANY
https://docs.conan.io/en/latest/reference/conanfile/attributes.html#options
class FooConan(ConanFile):
options = {"custom_env": "ANY"}
default_options = {"custom_env": tools.get_env("MYENVVAR")}
def package_id(self):
del self.info.options.FOO # Doesn't affect the package ID
def package_info(self):
self.env_info.FOO = self.options.custom_env
The example above shows a recipe which receive a custom option, and it doesn't affect id, and is used for customer environment.
Anyway, self.env_info in not supposed to be used when installing, it's consumed when building a package. The virtualrunenv is able to change your PATH, which can useful if you need to run a specific tool which is packaged.
A second way, and more dynamic, as cpp_info is dynamic, you can consume directly from user environment:
class FooConan(ConanFile):
...
def package_info(self):
self.env_info.FOO = tools.get_env("FOO", "waka waka")
In this case, when running conan install <ref> -g virtualenv, the environment.sh.env will contain FOO=waka waka OR, if FOO is declared in consumer environment, the FOO's value from consumer env.
If you want to affect your requirements, using env vars, do not do it! Requirements affects the package ID, Conan options is the best solution.
I am busy with configuring our new TFS 2015 server (on premises) and trying to get the new vnext builds to work properly.
What I now have are some extra powershell scripts that increase the version number of my assemblies.
It also changes the buildnumber in TFS by calling the API method (see tfs rest api). My json body only sends the new build number (eg. {"buildNumber": "1.0.1.1234"}) and this works fine.
Now I have added some major, minor and patch version variables in the build definition for the version. Once the build is done this should be updated and so I thought to do the same kind of thing and just send an update API call to the corresponding builddefinition endpoint. The documentation says the revision number is mandatory so I have added that. For the rest I only added the changed variables.
The api call works, but the nasty thing is that it will update the whole definition and clear out all the other settings which I did not provide in the json body. I also tried first getting the defintion through the API, changing the json values for the variables and send that back but that didnt work correct also.
So does anybody know a good solution for this?
As a workaround what I did for now is adding a dummy build definition (eg. "_ProjectVersion") totally empty except for the variables and my build task now uses that build definition to get the latest version numbers and update them. So the api call still empties that whole build definition but since it only contains my variables I dont mind.
I am also doing this in powershell since all scripting should be automated and done in powershell.
The problem I have is that the API call to get the json of an existing BuildDefinition returns invalid json when managed in powershell.
For example the "#{multipliers=[]; will fail with 'must have at least one value' even though a 'json validator' may report as Valid. The correct json is {"multipliers": "[]",
I installed the MvcScaffolding4TwitterBootstrapMvc package which is based on the scaffolding stuff Steve Sanderson has done. Now I'm attempting to create a new view based on it and I'm just receiving PS errors.
I'm typing this:
Scaffold View LocationType CreateOrEdit -Template _CreateOrEdit
(I've tried other view templates as well)
I receive this error message:
t4(115,64) : error CS1061: Compiling transformation: 'EnvDTE.CodeProperty' does not contain a definition for 'IsScaffoldable' and no extension method 'IsScaffoldable' accepting a first argument of type 'EnvDTE.CodeProperty' could be found
At packages\MvcScaffolding4TwitterBootstrapMvc.1.0.2\tools\RazorView\MvcScaffolding.RazorView.ps1:42 char:27
Obviously the template is causing the error because it can't find something (maybe the T4 library)? But I'm not really sure what or where I'd fix it.
It looks like the IsScaffoldable extension method doesn't exist in the version of the T4Scaffolding.DLL that is installed with the NuGet package.
If found this work item which lead me to GitHub and I see this method exists. Since I'm not really using this attribute, I decided it's probably just simpler for me to remove the .IsScaffoldable() call from the T4 template instead of pulling down the source and compiling a new version of T4Scaffolding.
I am using TeamCity 7.1. I want to get a list including the last build of each build configuration (build type) that is currently not running. I found this question: TeamCity - How do you get a list of the last finished build of each project through rest api? but the REST URI in the answer did not work for me.
<teamcity-server>/httpAuth/app/rest/builds?locator=sinceBuild:(status:failure)
seems to work and gives me all builds that succeeded after failing before.
But the opposite
<teamcity-server>/httpAuth/app/rest/builds?locator=sinceBuild:(status:success)
does not return any builds.
I know that I can get all build types, iterate though them and get the most recent finished build using
<teamcity-server>/httpAuth/app/rest/buildTypes/id:<build-type-id>/builds/running:false?count=1&start=0
("count=1&start=0" may not be necessary)
but I am not really sure that what I get is really the latest build. Also this requires many REST calls for all build types. A neat solution would use only one REST call.
Any ideas?
As per the TeamCity REST API documentation from JetBrains, the builds can be located either of the following ways:
<teamcity-server>/httpAuth/app/rest/buildTypes/id:<build-type-id>/builds/running:false,status:success
OR
<teamcity-server>/httpAuth/app/rest/builds/running:false,status:success
This is must to have the buildType is being suffixed by a <buildTypeLocator> as per the current REST API if you are trying to query something under the buildType and <buildTypeLocator> can be id:<btXXX_internal_buildConfiguration_id> or name:<Build_Configuration_name> (Quote from documentation). So it is must that you need to specify build id or build name.
But, the ideal way as you expected will be something like:
<teamcity-server>/httpAuth/app/rest/buildTypes/builds/running:false,status:success
Probably, you can raise this up in TeamCity Support I suppose.
Given:
Wix 3.0 is used to create MSI.
The product consists of multiple feature.
Each feature has few sub features. It’s a standard MSI feature tree.
Each feature or sub feature depend on multiple external components.
E.g. .NET 4, ASP.NET etc
Custom action written in C# using Wix 3.0 SDK processes these
dependency and evaluates if components are present or not for a
given set of features.
At time of install if dependent component is missing for given
selection of features, installation fails.
To achieve:
Ability to execute prerequisite check, which is already done in MSI as custom action during installation, without installing MSI on a given machine.
Failed Attempts:
1)
Custom action have function signature like this
[CustomAction]
public static ActionResult ProcessFeaturePrerequisite(Session session);
In order to get session object I used following API present in Wix 3.0 SDK
Session session = Installer.OpenPackage("Pathto\\Product.msi", true); // true doesn’t install it. Also tried with false, but didn’t work.
When I invoke the above method with above session following things fail.
session.Features["SomeFeature"].CurrentState;
This throws exception.
System.ArgumentException was unhandled by user code
Message=Feature ID not registered. SomeFeature
Source=Microsoft.Deployment.WindowsInstaller
StackTrace:
at Microsoft.Deployment.WindowsInstaller.FeatureInfo.get_CurrentState()
Also below critical API which determines prerequisite status always returns false.
session.EvaluateCondition(prereq);
2)
I know a command line way to specify features to the above MSI and install it. It goes like this
msiexec /i "Product.msi" ADDLOCAL=ALL REMOVE="Foo,Bar "
I couldn’t find any API in SDK which allows me to pass additional params which returns session object without starting installation. My guess is passing such param will make session.Features more valid.
Questions:
So how do I achieve above goal?
Is there
any API in Wix SDK which allows me to call custom action without
invoking installation?
any way to invoke custom action from command line for a given MSI
without installing?
any way to make Wix to change MSI into accepting a command string
containing custom action name which only evaluates the action?
any better way to do the same?
I suppose you're trying to solve the problem with the wrong tool. As far as I understand, you would like to check the installation prerequisites from inside a certain tool, but not from the installation. As long as the functionality is implemented as a custom action in the MSI package, you'd like to utilize that functionality in order not to duplicate the code.
I would choose a different way in your situation:
Extract the functionality which actually checks for prerequisites into a separate assembly, e.g. checkprereq.dll
Refactor your custom action to reference checkprereq.dll. Note that you'll have to add checkprereq.dll to your Binary table as well as the customaction.dll. You should divide the responsibility here: the custom action part works with MSI stuff - in your case, it's defining which prerequisites to check based on the combination of features a user selected - and the functional part - the actual prerequisites verification, which is done by checkprereq.dll
Use checkprereq.dll separately when you need to check prerequisites not triggering the installation process
The attempts you've outlined here demonstrate an important false assumption: the session object at install time is the same as the installation object you get by just opening the MSI database for read only purpose. IT'S NOT TRUE! Actually, I doubt it makes any sense to reference the session object outside the installation transaction. As its name states, it is an installation session, that is, available in process - not a static thing.
The MSI package should be treated just as a database when it is just a file and not a running installation. Hence, only static information living in MSI package can be queried and used when you just open it for reading and not installing. I mean you can query the Feature table, for instance, but don't expect it to contain information which makes sense in installation time only, like whether a user chose a feature for installation or not.
Hope this makes sense and shows you the right direction.