Add to conan virtualenv from consumer - conan

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.

Related

What is the proper way to define custom attributes for conditional compilation?

I'd like to be able to pass a flag to cargo test to enable logging in my tests, when I need to debug them.
I've come up with something like:
#[cfg(logging)]
// An internal module where I define some helper to configure logging
// I use `tracing` internally.
use crate::logging;
#[test]
fn mytest() {
#[cfg(logging)]
logging::enable();
// ..
assert!(true);
}
Then I can enable the logs with
RUSTFLAGS="--cfg logging" cargo test
It works but it feels like I'm abusing the rustc flag system. It also has the side effect of recompiling all the crates with my logging flag, which (besides the fact that it takes ages) may be an issue if this flag is used by one of my dependency some day.
Is there a better way to define and use custom attributes? I could add a feature to my cargo manifest, but this is not really a feature since it's just for the tests.
You wouldn't usually recompile your application, there's no need to: you can use an environment variable. For example:
if std::env::var("MY_LOG").is_ok() {
logging::enable();
}
You can then dynamically decide to log by calling your application with
MY_LOG=true cargo run
or, when already compiled,
MY_LOG=true myapp
You would usually configure more than just whether the log is on, for example the log level or the level destination. Here's a real example: https://github.com/Canop/broot/blob/master/src/main.rs#L20

Generating CRUD in symfony 4

After releasing Symfony 4.0, there is no support for SensioGeneratorBundle. hence the command php app/console generate:doctrine:crud is not available.
They suggest to use MakerBundle, but I could not find appropriate replacement for CRUD generation.
Could anyone help?
You can use the make command in Symfony4+ (and it's quite an improvement!), from the MakerBundle:
php bin/console make:crud
It'll prompt you for which entity you want the crud for. It generates a controller with index, new, update, view and delete methods in /src/controller, with matching templates in /templates.
Useful to know: If you run make:entity, and later run that command again and enter an existing entity, it responds with:
Your entity already exists! So let's add some new fields!
At the moment MakerBundle supports just a few core commands. You can see the list here. Unfortunately there's no CRUD generator. But there some discussion about it in the issues so you can follow what will be done.
If what you need is just a generator for boilerplate code and not a more structured solution like EasyAdminBundle you should consider creating your own maker.
Symfony4 (thanks to #jelle)
composer require symfony/maker-bundle --dev
composer require symfony/form symfony/validator symfony/twig-bundle symfony/orm-pack symfony/security-csrf
php bin\console make:crud
The class name of the entity to create CRUD (e.g. BravePuppy):
>
first install pre-req packages
composer require twig-bundle security-csrf
and then you can run
php bin/console make:crud
after that just enter your entity name which you want to curd
The class name of the entity to create CRUD (e.g. BlogPosts):
>

Puppet Learning VM: Manifests and Classes (Ruby)

I am working ON Puppets Learning VM which uses Ruby which I am not too familiar with. I am stuck on Exercise 5. Manifests and classes, Task 2 https://kjhenner.gitbooks.io/puppet-quest-guide/content/quests/manifests_and_classes.html
In the previous Task I create cowsay.pp :
class cowsayings::cowsay {
package { 'cowsay':
ensure => present,
provider => 'gem',
}
}
Then in task two I am suppose to create the same file in another location with instructions:
Task 2:
If you were going to apply this code to your production infrastructure, you would use the console's node classifier to classify any nodes that needed cowsay installed with the cowsay with your cowsay class. As you're working on a module, however, it's useful to apply a class directly. By convention, these test manifests are kept in an examples directory. (You may also sometimes see these manifests in the tests directory.)
To actually declare the class, create a cowsay.pp test in the examples directory.
vim cowsayings/examples/cowsay.pp
In this manifest, declare the cowsay class with the include keyword.
include cowsayings::cowsay
I am not sure how to create this second file and where to add this line. I have tried both:
class cowsayings::coway {
include cowsayings::cowsay
package { 'cowsay':
ensure => present,
provider => 'gem',
}
}
and
class cowsayings{
include cowsayings::cowsay
}
Although it does not seem to be working and when I run it, it does not install cowsay correctly in Task 3 (in the link above that I posted
The manifest in the examples directory just needs that one line with "include cowsayings::cowsay".
There are two tasks that have to happen with puppet, "defining" classes and "declaring" them. The cowsayings/manifests/cowsay.pp contains the definition, but you need to actually declare the class in order to make something happen.
That's what puppet apply cowsayings/examples/cowsay.pp does, it declares the class.

How to execute custom action present in MSI without invoking installation?

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.

Using environment vars in non-rails cucumber test

I created a simple smoketest for a portal running java/tomcat/jahia (cms) fronted by cache servers and big ip. Cucumber + Webrat + Mechanize is a good fit for a simple smoketest of this setup. (and it has been very easy to get started).
Right now I have hardcoded into /features/support/paths.rb the following lines:
module NavigationHelpers
#PATH="http://production-environment"
#PATH="http://staging-environment"
#PATH="http://test-environment"
PATH="http://localhost:8080"
#
def path_to(page_name)
case page_name
when /the homepage/
"#{PATH}/"
when [...]
...
end
end
end
World(NavigationHelpers)
Right now I manually switch the comments when I want to test different environments. The issue here is I'd love to get rid of the constant PATH and put a default value inside one of the support files. And i also want to be able to feed cucumber with this environment variable from the command line like so:
cucumber ENV=staging
How do you cope with this issue? Any suggestions? Links to code that deals with this? Snippets?
You can pass environment variables to Cucumber like you have done with ENV. Each environment vriable will then be available in Ruby's ENV constant. More details in the Wiki
(I just added this page - the feature has been around since 0.3.90 but was only ever mentioned in the History.txt file).