Following this (unreadable) forum post, I thought it was fitting to post it up on stack overflow for future generations who search for it.
How to pass arguments for gym environments on init?
In the meantime the support for arguments in gym.make has been implemented, so you can pass key word arguments to make right after environment name:
your_env = gym.make('YourEnv', some_kwarg=your_vars)
The gym version that I'm running is 0.12.4.
UPDATE: This is supported from version 0.10.10.. Reference. Thanks #Wojciech.
Method 1 - Use the built in register functionality:
Re-register the environment with a new name
For example:
'Blackjack-natural-v0'
Instead of the original
'Blackjack-v0'
First you need to import the register function:
from gym.envs.registration import register
Then you use the register function like this:
register( id='Blackjack-natural-v0', entry_point='gym.envs.toy_text:BlackjackEnv', kwargs={'natural': True} )
Method 2 - Add an extra method to your env:
If you can just call another init method after gym.make, then you can just do:
your_env = gym.make("YourEnv")
your_env.env.your_init(your_vars)
Related
I'm currently trying a fetch a parameter for my pipeline through the CDK SSM Parameter library, however I seem to face a weird issue:
CfnParameter at 'nonProdAccountId.Parameter' should be created in the scope of a Stack, but no Stack found
However, I'm rather confident that I am fetching my Parameter value in the Scope of a Stack (the BackendPipelineStack).
//cdk.ts aka my entrypoint
const app = new cdk.App()
...
new BackendPipelineStack(app, "BackendPipelineStack", {
nonProdAccountId: StringParameter.fromStringParameterName(app, "nonProdAccountId", "nonProdAccountId").stringValue,
apiStack,
commonInfraStack,
deploymentStack,
})
Am I missing something?
TIA
Right now, you're importing the StringParameter in the scope of the App. The first argument in every Stack or Construct is the scope.
You can create stacks in the scope of an App, but you can't create constructs in the scope of an App - they have to be created in the scope of a Stack.
You need to move the import into the stack, and use the stack as the scope for the import (passing this instead of app).
So you would change
nonProdAccountId: StringParameter.fromStringParameterName(app, "nonProdAccountId", "nonProdAccountId").stringValue,
to
nonProdAccountIdParamName: "nonProdAccountId",
And import the parameter inside of the stack with
const nonProdAccountId = new StringParameter.fromStringParameterName(this, "nonProdAccountId", nonProdAccountIdParamName).stringValue;
Given the class
class TestClassRequiredMethods:
called = False
def publish_db_flaws(self, x):
self.called = True
I'd like to check if the class has a certain method and an expected amount of params.
I solved half of it, now I can check if the object has the attribute but I can't find a way to check how many params are expected in this method.
if not hasattr(publisher, 'publish_db_flaws'):
raise TypeError('The publisher must contain a "publish_db_flaws()" method')
Answer
The accepted answer is working fine for Python 2, if you are working with version 3, you may use:
import inspect
class Publisher:
def publish_db_flaws(self, params_string:str, params_integer:int):
pass
publisher = Publisher()
print(inspect.signature(publisher.publish_db_flaws))
print(inspect.getfullargspec(publisher.publish_db_flaws))
inspect.signature will bring just the signature of the method.
inspect.getfullargspec shows a very complete information about the params.
In addition to hasattr you can use callable(publisher.publish_db_flaws) to check if the attribute is really a callable function.
More detail is available using inspect module as hinted in the comment by ForceBru. inspect.getfullargspec(publisher.publish_db_flaws) gives you information about argument names, if the function uses varargs or keyword args and any defaults.
Similar information is available via inspect.signature. This gives you a Signature object which has a __eq__ method for easy comparison. Note, that this is the preferred method for Python3. getfullargspec is to be used if you need compatibility with the Python2 interface.
Or, the goal: How can I take a single package from Nix unstable in a declarative manner?
I'm new to NixOS and currently trying to install a newer version of Consul than the default 0.5.2 of my NixOS version (latest stable). I'm attempting this by overriding the derivative in my /etc/nix/configuration.nix.
I'd like to keep running stable, but I found unstable had the version of Consul that I wanted (0.7.0) already, and so I decided to use this package's attributes as a starting point to override https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/consul/default.nix
I copied it for most part into my configuration.nix, here are the relevant sections:
nixpkgs.config.packageOverrides = pkgs: rec {
consul = pkgs.lib.overrideDerivation pkgs.consul (attrs: rec {
version = "0.7.0";
name = "consul-${version}";
rev = "v${version}";
goPackagePath = "github.com/hashicorp/consul";
src = pkgs.fetchFromGitHub {
owner = "hashicorp";
repo = "consul";
inherit rev;
sha256 = "04h5y5vixjh9np9lsrk02ypbqwcq855h7l1jlnl1vmfq3sfqjds7";
};
# Keep consul.ui for backward compatability
passthru.ui = pkgs.consul-ui;
});
};
environment.systemPackages = with pkgs; [
vim
which
telnet
consul-ui
consul-alerts
consul-template
consul
];
I'm running nix-build (Nix) 1.11.2 which throws:
$ nixos-rebuild switch
building Nix...
building the system configuration...
error: cannot coerce a set to a string, at /etc/nixos/configuration.nix:19:7
(use ‘--show-trace’ to show detailed location information)
When I look at line 19 it's where name is set to "consul-${version}".
Why there is type-coercion going on here? Any tips will be greatly appreciated!
I'm also wondering if there is a better way to run just a single package in unstable, yet doing so declaratively from configuration.nix, rather than imperatively?
To add to what Rok said:
Which should point you that an error actually happens at passthru, line. If you comment it out it will probably build. I'm assuming some recursive calls are at play here and error occurs when it tries to evaluate consul/consul-ui packages.
If you're just starting out, you can safely ignore what follows and perhaps come back to it if/when you're curious about the nitty-gritty.
The problem here is that overrideDerivation is a kind of low-level approach to overriding things. Behind stdenv.mkDerivation, we have a much smaller primitive function called derivation. The derivation function takes some attributes and (more or less -- see the docs for the finer details) just passes those attributes as environment variables during the build. The stdenv.mkDerivation function, on the other hand, has a whole bunch of smarts layered on top that massages the attributes given to it before passing them onto derivation -- and in some cases, as is the case with passthru, it doesn't pass the attribute to derivation at all.
Back to overrideDerivation: it takes the final, tweaked attributes that stdenv.mkDerivation would pass to derivation, and just before that happens it allows you to override those attributes with the function you give it (e.g. that implies that, at that point, passthru has already been removed). When your function adds a passthru, that makes its way into derivation, which then wants to coerce the value of passthru into a string so it can make passthru an environment variable during the build; however, because passthru now points at a attribute-set, and such coercion isn't supported, Nix then complains.
So this sort of puts us in an odd situation. To illustrate, I'll copy the source for the consul package here:
{ stdenv, lib, buildGoPackage, consul-ui, fetchFromGitHub }:
buildGoPackage rec {
name = "consul-${version}";
version = "0.6.4";
rev = "v${version}";
goPackagePath = "github.com/hashicorp/consul";
src = fetchFromGitHub {
owner = "hashicorp";
repo = "consul";
inherit rev;
sha256 = "0p6m2rl0d30w418n4fzc4vymqs3vzfa468czmy4znkjmxdl5vp5a";
};
# Keep consul.ui for backward compatability
passthru.ui = consul-ui;
}
(Note that buildGoPackage is a wrapper around stdenv.mkDerivation.)
You might be familiar with e.g. consul.override, which allows you to supply different inputs (e.g. maybe a different version of consul-ui, or buildGoPackage), but it doesn't allow you to override things that aren't inputs (e.g. src, passthru, etc). Meanwhile, overrideDerivation allows you to modify the attrs given to derivation, but not the ones given to stdenv.mkDerivation. Ideally there would be something in-between, that would allow for manipulating the attrs given to stdenv.mkDerivation, and it so happens that there's a PR open to address this:
https://github.com/NixOS/nixpkgs/pull/18660
Welcome to Nix/NixOS :)
Whenever you need to know more about the error you can use --show-trace and that would give you more verbose error. In your case you would see something like
error: while evaluating the attribute ‘passthru’ of the derivation ‘consul-0.7.0’ at /home/rok/tmp/consul.nix:6:3:
cannot coerce a set to a string, at /home/rok/tmp/consul.nix:6:3
Which should point you that an error actually happens at passthru, line. If you comment it out it will probably build. I'm assuming some recursive calls are at play here and error occurs when it tries to evaluate consul/consul-ui packages.
As for overriding only one package from unstable channel something like this is needed
let
unstable_pkgs = import ./path/to/unstabe/nixpkgs {};
# or
# unstable_pkgs = import (pkgs.fetchFromGitHub {...}) {};
in {
...
nixpkgs.config.packageOverrides = pkgs: rec {
consul = unstable_pkgs.consul;
};
...
}
I haven't try the above, but I'm assuming it will work.
I am wondering how we can pass variables between two step definitions files.
I found this How to share variables across multiple cucumber step definition files with groovy but their structure is different from mine, because I am not using classes in step definition.
The following is my two step definition files.
Feature File 1
Scenario: Consumer registration
When I try to register with my details with "memberNo" mem no.
Then I should be able to get success response
stepDef1
When(~'^I try to register with my details with "([^"]*)" mem no.$') { String memdNo ->
sMemdNo = memNo + getRanNo()
// more code here
}
Feature File 2
Scenario: Event Generation
When I activate my account
Then I can see the file having "logName" event
stepDef2
Then(~'^I can see the file having "([^"]*)" event$') { String logName ->
eventFile = GetLogtData(logName , sMemdNo )
// more code here
}
So, as per the above I want to get the value of sMemdNo from stepDef1 and use it in stepDef2.
I will recommend that you use the World, to store global variables needed across step definitions.
You can see an example here: cucumber-jvm-groovy-example.
You can combine the World with a Factory and/or dependency injection pattern.
To use variables between steps you can add the variable at the top of the steps file (groovy or java), and the variable used in one step will have the value available for other variable.
Example
Result
I need to remember the last parameter values when I begin a new build with parameters.
I have two string parameters:
${BRANCH}
${ServerSpecified}
On the first build execution I need those values in blank, but for the second execution, I need the values of the first execution, in the third execution the values of the second execution, and so on...
Do I need to install a plugin? I have tried using dynamic param with groovy, but I can't extract the last value. Does anybody know how to do this or have any other idea?
There is a Rebuild plugin that would allow you to re-build any job of interest. It also allows you to modify one or more of the original build parameters
In order to retrieve parameters from previous executions, you can follow this approach in your pipeline:
def defaultValueForMyParameter = "My_Default_Value"
node('master') {
parameterValue = params.MY_PARAMETER ?: defaultValueForMyParameter
}
pipeline {
parameters {
string(name: 'MY_PARAMETER', defaultValue: parameterValue, description: "whatever")
}
...
}
This code keeps track on the last value used for the parameter allowing to change it before or during the run. If the parameter does not exist in the job, it will be created and the default value will be assigned to it.
Yes, it looks like you are trying to invent something like Version Number Plugin:
This plugin creates a new version number and stores it in the
environment variable whose name you specify in the configuration.
So you can as many variables as you want.
No one mentions the Persistent Parameter plugin, which is the one I use.
Supports string parameters, choice, and more.