I love Tuist, I’ve been using it for a long time as a local build tool. I just recently starting integrating the server features such as build caching and selective testing into my application and while those features are great and incredibly useful, I strongly dislike that those features are enabled by default in the CLI. When I run tuist generate locally, the default should be --no-binary-cache and using the server features, especially locally, should have to be explicitly enabled.
The reason I think it’s a bad idea is two-fold:
I accidentally incur cache hits all the time now. I often forget to append --no-selective-testing or --no-binary-cache to tuist generate and tuist test commands, things that I’ve been running for years but now can incur a remote cache hit
Other engineers that contribute to the project that don’t know Tuist or iOS as well, such as a backend engineer that may open the app just for local development, are also accidentally incurring cache hits because they a) dont know about the server side features and b) are only familiar with the tool in its most basic invocations.
IMO and TL;DR, any paid feature should be opt-in; it might be just be but it wasn’t immediately apparent to me that it’s turned on by default.
This is not true – unless you specify your fullHandle in Tuist.swift, nothing leaves your machine to our servers. Adding the fullHandle is fully opt-in.
It is true we automatically try to use binaries – but unless your project is connected with a remote project, again, it never leaves your machine.
Similarly, if you do end up adding a fullHandle in your Tuist.swift (and thus opting into server capabilities), anybody on the team still needs to authenticate with the server by calling tuist auth login and signing up – again, an action that must be done explicitly.
You are never charged unless you upgrade to a Pro plan. All accounts are created with the Air plan (see pricing) – if you go over thresholds, the server-based paid features (remote caching and selective testing) simply stop working. In other words, upgrading to the Pro plan (and thus possibly having to pay for the service) has to be an explicit opt-in action that you have to take.
I might be missing what exactly casued your frustration on your end? We would never want to charge or force server-based features onto people – both are fully opt-in and you can use them if you want, but also, you can use the fully free, open-source, MIT, local capabilities of the CLI. We’ll be happy either way that Tuist makes your life slightly better
I dont think that’s really true though because the Tuist.swift file is checked into version control so if I want to opt in or opt out, it’s for the entire team. I can’t easily have it be opt in or opt out via that mechanism for individual users.
Also, there are features in Tuist that are free, like previews and build analysis, that I want to leverage without the fear of invoking cache hits but like you said, I need a handle in the Tuist.swift file to use those free features. Which in turns, opens me up to invoking remote hits with other commands by accident.
I also believe this isn’t true either, I tried yesterday and rather than just stopping working, tuist wouldn’t generate or build any of my projects locally and I received an error message that I had reached the cap.
I can understand this point of view, but we believe we’re doing our best at making the server and paid features opt-in without causing too much friction when teams actually want to use those features at their fullest potential. We find it also very rare for folks not wanting to leverage remote caching also for local environments once they use them in their CI environments (and upgrade to Pro plans) as it pays a lot of dividends in making engineers productive. This is why the default is set as it is.
If you want to change defaults in your team, you can use environment variables such as TUIST_GENERATE_BINARY_CACHE or dynamic configuration. We would never want to charge you for features you didn’t want to be using, so we’re more than happy to deduct hits that came from non-CI environments for the current month. Send me a DM if that’s the case.
In other words, those features stopped working as I mentioned You get an error, so you’re aware that you went over the plan and, yes, you do need to specify --no-binary-cache to get the generation working. Again, we think this is the right default, but you are of course free to disagree.
I mean we do love Tuist for sure and plan to keep using it for local dev at the very least, ya’ll have done a fantastic job at making such a great tool and fostering an incredible development community. It’s just engineering decisions like this strike me as odd and counterintuitive and I’m not alone in that; I asked a bunch of other engineers I know and that I work with and every single one thought the behavior should be flipped.
I think the real issue is that the opt-in behavior is decently opaque. Until you said it, I didn’t know that adding the handle was akin to opting in, I just thought that was setting up a tuist account so we could leverage server features like build analytics and the Tuist registry. It wasn’t clear that then running the commands I’ve been running for years like tuist generate would now be incurring cost. I think that’s the crux of it honestly, that adding a Tuist account fundamentally changes the behavior of the CLI commands.
And the env var flags get into the same issue, I have to actively remember to append those. A .env file would help here but since Tuist doesn’t support that, we’re a bit stuck. Our development flow just isn’t supported well where we don’t care about speeding up local development and only care about CI.
We think it’s reasonable that if you are a) authenticated b) have cache set up, we’d try to use the remote cache set up if it’s available. This is the behavior I would expect and this is the first time after running the remote cache for a while that the current behavior is surprising. Again, can see your point of view, but we might just have to agree to disagree on this one. Please, do know there’s no malicious intent behind this to try to somehow enrich ourselves from all this. We’re trying to offer the best tool and service and all our decisions are based on that.
They only incur cost if you upgrade to a plan, as mentioned before.
We’re not against adding this capability, but as I mentioned on Slack, we think mise is already the best tool for this (and I’m sure there are other). This is sort separate to our decision, although I understand it would better enable exactly how you want to be using the tool.
Perfectly understandable; I definitely understand the rationale behind the decisions. Thank you for being so responsive! Again, we really love Tuist, none of these are necessarily deal breakers, I think we just have a different perspective on the Api functionality.
All feedback is appreciated and thanks for putting your trust in us
We’ll certainly take your feedback into account when making future decisions. And if you have other needs or feedback apart from the .env support, we’re always keen to hear that, too
