Comments (7)
No polling is Slack please. We need to prepare a comprehensive and consistent specification of the new CLI, agree on the interface, and then decide in which order we'll add the features. But the design must be done at once, to avoid breaking changes or surprises down the line. I asked @netmilk to take charge of the CLI design, we need to kick this work off soon (cc @mtrunkat)
from apify-cli.
+1 to this. In Actor specification we suggested to use --json
to force JSON input/output for all commands.
from apify-cli.
In Actor specification we suggested to use --json to force JSON input/output for all commands.
I'd be fine with this too, although I'm worried it could clash with future options maybe? Is this something we should make a poll about on slack, or just go with what the spec says?
from apify-cli.
There is still one very important unresolved question, do we want to ship v1 now, or wait for this new API? Because there are lots of internal improvements we did over the past quarter and we planned to ship it already, only to see @barjin presenting the new API proposal in the sprint we wanted to ship :]
I think it would make sense to ship it now, because the new proposal might take weeks if not months to be agreed on, and it would be a shame to hold the improvements we have in the master branch for too long. Maybe it would make sense to ship it as v0.20 if we plan to do API overhaul soon, since the changes in master are mainly internal (plus a few features and smaller BCs). Or we can just wait, doing both in v1 would be IMO the best, I am just afraid that the discussion could be lengthy (implementation should be rather simple).
Worth noting that we currently build v1 beta releases already from master, so if we decide to ship it as v0.20 it might be confusing for those who already tried the beta. Hard to guess if there are people outside of Apify who tried it.
from apify-cli.
There is still one very important unresolved question, do we want to ship v1 now, or wait for this new API?
I believe the --raw-output
flag (or whatever we settle upon) is orthogonal to the new API and it can be added whenever, with or after v1, as it should be backwards compatible. Am I missing something?
Maybe it would make sense to ship it as v0.20 if we plan to do API overhaul soon
Agreed, it'd be weird to release v1 while already planning to overhaul the API and release v2.
We also need to decide whether certain logs should be printed to stderr instead of stdout (like the logs for an actor call).
This is the way. It should also be a different issue though.
from apify-cli.
My personal perspective here:
There's nothing necesiraly wrong about releasing 1.x.x
with the minor breaking changes and then, even shortly after that, releasing 2.x.x
, introducing the new design of the CLI API.
I'd love to see the release (deployment) conventions streamlined across all our tooling, focused on merging every meaningful work as soon as possible to the master and release instead of hoarding work in branches. The sooner users use it, the sooner we have feedback, and the sooner we can move on.
I'd love to disconnect the versioning from emotions as semantic-relese
intends, and the communication around major improvements wrap around named milestones like The new CLI API design
instead of v1
.
How does that sound?
from apify-cli.
I think it makes more sense to ship 0.20 now, since we haven't really done a major API overhaul since the very beginning, and now we are likely gonna end up with that - I hope we can all agree that such thing suites more into a v1 release (in the end you were the one pointing out v1 should be about stabilizing the API, what we did until now did not touch the user-facing API very much).
I also don't like to hoard stuff in branches (and we don't do that here, the work is in the master branch for quite some time, available for testing via beta releases), on the other hand, breaking releases are the one case where I feel it's a good thing - good for our users to be more specific. Who would want to see multiple breaking releases over a short period, having to think about upgrading guides and whatnot?
from apify-cli.
Related Issues (20)
- Clean up `apify run` to move logic that is runtime dependent to ProjectAnalyzer
- Update CLI help + doc with basic troubleshooting instructions
- Enhance help and doc of `apify init` command for Scrapy wrapping functionality HOT 1
- New release process
- `apify call` to support input passing HOT 2
- Add spec to shell autocomplete tool Fig HOT 2
- Interface for making "raw" API calls
- Storage isn't purged for non-crawlee Apify SDKv3 projects HOT 11
- `apify run --purge` doesn't purge HOT 5
- apify push and call do not validate whether they are in an Actor folder HOT 3
- `actor:push-data` doesn't work in the Apify Platform HOT 4
- Better CLI API HOT 7
- Output from warnings doesn't go to `stderr` and breaks working `*nix` integrations even on otherwise non-breaking releases HOT 4
- Cryptic error message when `actor.json` is an invalid JSON
- Figure out a better auth file structure for future extensibility
- Experiment with Bun bundling for distributing the CLI as a single-file executable HOT 1
- Actor.getInput returns null HOT 7
- Version 0.20.0 installed via NPM fails to work HOT 3
- Clean up the purging logic for crawlee projects
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from apify-cli.