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

Remove Shell Process #860

Closed
cdavernas opened this issue May 28, 2024 · 5 comments
Closed

Remove Shell Process #860

cdavernas opened this issue May 28, 2024 · 5 comments
Assignees
Labels
area: spec Changes in the Specification change: feature New feature or request. Impacts in a minor version change
Milestone

Comments

@cdavernas
Copy link
Member

What would you like to be added:

Remove the shell process, as suggested by @fjtirado in #859.

Why is this needed:

  • Is not portable if not restricted to a specific OS
  • There is, by definition, an isolation concern when using commands, even though runtimes can easily choose to solve them by... using containers, for example.
  • The exact same functionality can be achieved in a fully isolated and portable way using containers, making it, at best, redundant.
@cdavernas cdavernas added change: feature New feature or request. Impacts in a minor version change area: spec Changes in the Specification labels May 28, 2024
@cdavernas cdavernas added this to the v1.0.0-alpha1 milestone May 28, 2024
@fjtirado
Copy link
Collaborator

fjtirado commented May 28, 2024

I believe we all agree our goal should be to achieve full portability of spec files across implementors.
Thats why I think we need to replace shell, which have security, portability and performance implications, by a set of simple task which are universal and might be used to compose another more complex task.
Then, implementors can implement these single task the way they see fit (using shell, an operating system call or using a portable language library)
We might start with a small set and then add new ones base on user feedback.
One lame example.
"dump": has as arguments a message (which is a literal string or an expr), a destination: stdout, stderr or file path (expressed as an array to avoid SO dependant operation) and that just append the stirng to stdout, stderr or file path.
Im noy saying that is really needed (thats a different discussion) but an example of iteraction with the underlying file system we might want to support in the spec.

@fjtirado
Copy link
Collaborator

fjtirado commented May 28, 2024

Maybe the conclusion is that these set of task size is zero ;) and we can just remove shell ;). But probably we need "primitives" to create, read from, write to and delete files (logging is just a special case of write)

@ricardozanini
Copy link
Member

@cdavernas Maybe moving this one to extensions instead of removing it?

Copy link

github-actions bot commented Aug 4, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@cdavernas cdavernas self-assigned this Aug 21, 2024
@cdavernas
Copy link
Member Author

@cdavernas Maybe moving this one to extensions instead of removing it?

Unhappilly, I don't think that it would address the feature set nor the issues at hand, which can by the way be extended to scripts.

Removing shell and/or script is IMHO a bad idea, as we would drastically reduce the ability for less technical authors to painlessly achieve a lot of use cases.

I am therefore taking the freedom to close this issue in favor of #998, and will eventually reopen it depending on the outcome of said issue.

@github-project-automation github-project-automation bot moved this from Backlog to Done in Progress Tracker Aug 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: spec Changes in the Specification change: feature New feature or request. Impacts in a minor version change
Projects
Status: Done
Development

No branches or pull requests

3 participants