Warning: Package ReinforcementLearningEnvironments does not have PyCall in its dependencies about reinforcementlearningenvironments.jl HOT 7 CLOSED

Why not just move the type definitions out of the file that is loaded with requires, but leave the rest as is? I could have a look at this in the next few days...

from reinforcementlearningenvironments.jl.

The reason is that we are using Requires.jl. Once JuliaLang/Pkg.jl#1285 gets resolved, we can switch to the new method.

Though PyCall is declared in [extras], it is only for testing.

from reinforcementlearningenvironments.jl.

I think Requires.jl is not well suited to how it is used for GymEnv (and others). I could not get GymEnv to be extensible in my own module through this package without removing the @require declaration for include("environments/gym.jl"). See this issue, which says that types and structs should not be defined in @require'd code.

It works fine in a REPL of course, but that is of limited use.

from reinforcementlearningenvironments.jl.

@AlexLewandowski Thanks for the link! I didn't know that when writing this package.

Right now, I don't have a good solution to it.

Previously we have registered several different packages, like ReinforcementLearningEnvironmentGym.jl and some others. Then we created this package with the help of Requires.jl for easier maintenance. Moving structs out of @required is not an option here since each 3-rd party environment has some specific dependencies which are not required by the basic environments. So now we have two options:

1. Split this package into different sub-packages again.
   Personally I don't want to distribute them into separate repos. A better solution maybe register them in sub-directories in this repo. (Ref: JuliaLang/Pkg.jl#1251)

2. Or we can wait and see if there're some elegant solutions in JuliaLang/Pkg.jl#1285 .

By the way, could you share more about what you want to extend with GymEnv?

from reinforcementlearningenvironments.jl.

Moving structs out of @required is not an option here since each 3-rd party environment has some specific dependencies which are not required by the basic environments.

Ah, yes, I see, it may not be as easy as I thought...

from reinforcementlearningenvironments.jl.

Some environments are just fine to move out. For example, AtariEnv doesn't have any specific types in its definition. And the definition of OpenSpielEnv is just general enough to be moved out.

But for GymEnv and MDPEnv, they have PyObject and POMDP constraint in its parameters. Maybe we are safe to just remove those constraints?

from reinforcementlearningenvironments.jl.

But for GymEnv and MDPEnv, they have PyObject and POMDP constraint in its parameters. Maybe we are safe to just remove those constraints?

We could check for these constraints in the constructor and make the fields parametric in the type def.

from reinforcementlearningenvironments.jl.