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

Support for additional py_binary kwargs in entry_point #600

Closed
phlax opened this issue Jan 7, 2022 · 5 comments
Closed

Support for additional py_binary kwargs in entry_point #600

phlax opened this issue Jan 7, 2022 · 5 comments
Labels
Can Close? Will close in 30 days if there is no new activity

Comments

@phlax
Copy link
Contributor

phlax commented Jan 7, 2022

🚀 feature request

Relevant Rules

  • entry_point
  • py_binary

Description

afaict, you cant pass kwargs - eg args, data etc into an entry_point rule, it would be handy if you could

Describe the solution you'd like

To be able to do something like

alias(
    name = "my_command",
    actual = entry_point(
        pkg = "my.upstream.command",
        script = "my.upstream.command",
        data = [":some_local_data"],
        args = ["$(location :some_local_data)"],
    ),
)

Describe alternatives you've considered

wrapping the entry_point one way or another to call it with the required data, args

@phlax
Copy link
Contributor Author

phlax commented Jan 8, 2022

one possible solution would be if you could use an entry_point alias in the srcs/main of a py_binary rule

i tried to do it but it needs a .py file, so maybe that wouldnt work with alias

@phlax
Copy link
Contributor Author

phlax commented Jan 8, 2022

@UebelAndre
Copy link
Contributor

#575 expands on the same pattern. I think there's value in having isolated targets but perhaps there can be an additional macro that defines a py_binary in place that allows you to add dependencies?

Or, perhaps with package_annotation (#589) a new field could be added that adds additional dependencies to the generated binary targets?

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_python!

@github-actions github-actions bot added the Can Close? Will close in 30 days if there is no new activity label Jul 20, 2022
@github-actions
Copy link

This issue was automatically closed because it went 30 days without a reply since it was labeled "Can Close?"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Can Close? Will close in 30 days if there is no new activity
Projects
None yet
Development

No branches or pull requests

2 participants