Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pydrake: Migrate pydrake.examples to example directories #9645

Closed
3 tasks
EricCousineau-TRI opened this issue Oct 10, 2018 · 3 comments
Closed
3 tasks

pydrake: Migrate pydrake.examples to example directories #9645

EricCousineau-TRI opened this issue Oct 10, 2018 · 3 comments
Assignees
Labels
component: pydrake Python API and its supporting Starlark macros priority: medium type: cleanup

Comments

@EricCousineau-TRI
Copy link
Contributor

EricCousineau-TRI commented Oct 10, 2018

Relates #8911.

At present, some components from //examples are bound and exposed via pydrake.examples. They should be removed.

If there is functionality that should be accessible via pydrake (or @drake// in general), it should live outside of //examples.

Process:

  • Put example-specific bindings into that specific //examples folder.
  • Deprecate existing pydrake.examples modules. (May involve code duplication to preserve backwards compatibility.)
  • Remove pydrake.examples

\cc @RussTedrake @jwnimmer-tri

@EricCousineau-TRI EricCousineau-TRI self-assigned this Oct 10, 2018
@EricCousineau-TRI EricCousineau-TRI changed the title pydrake: Remove pydrake.examples pydrake: Migrate pydrake.examples to example directories Oct 10, 2018
@RussTedrake
Copy link
Contributor

RussTedrake commented Oct 10, 2018

The other ideas/concerns that we discussed:

  • Can consumers of the binary release of drake run the examples? I suspect that many users will try drake via binary first/only. Letting them run examples seems valuable.
  • Can an example directory provide some form of installation? I'm thinking more clearly now of an example subdir as an application of drake (not part of libdrake.so). Like a separate repo that just happens to be collocated for convenience. In that mindset, it seems reasonable for a separate app to have it's own install logic/artifacts?

@jwnimmer-tri
Copy link
Collaborator

jwnimmer-tri commented Oct 10, 2018

Neither #9646 nor this issue formulates the way that makes the more sense to me. I will try to write up longer thoughts later, but to me the only important thing is whether the API to the artifact being shipped is via library calls (linking / loading) or via a binary program (new process). I am more than happy to ship any and all sealed binary demos -- where the stable interface to the user is the README.md and command-line arguments -- no matter where they live in the source tree. When the API is via a library (be it C++ headers or python module), I think it should not live in examples. In short, the only public targets of //examples (whether they be installed, or just consumed via drake_bazel_external) should be foo_binary or filegroup, not foo_library. I think that will make it much easier to clarify which library APIs are sensitive / stable.

@jwnimmer-tri
Copy link
Collaborator

Can an example directory provide some form of installation?

Per #4224, yes, the current intent is that all of the example applications are (or at least could be) installed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: pydrake Python API and its supporting Starlark macros priority: medium type: cleanup
Projects
None yet
Development

No branches or pull requests

3 participants