Announcing BLT’s End of Life about blt HOT 11 OPEN

Good session from Drupalcon Pittsburgh on using Robo (which BLT is built on) to do automated workflows...

https://www.youtube.com/watch?v=tVBDSTEiboU

from blt.

I want to chime in not just as an Acquia employee, but as a fellow user and advocate for BLT.

I hear you. It’s not fun to find out that a tool you've relied on is going to be EOL. It creates work for you and for other users like you. It affects the community that's grown around this tool. I don't like seeing that. And I certainly don’t like ending a project that I helped create.

But as someone who uses BLT to maintain several of my own Drupal sites, I firmly believe that this EOL, despite the pain, is the right choice for you, for me, for Acquia, and for the open-source community. I may be wrong, and if that’s the case, I hope that a new maintainer comes forward, and I’ll happily facilitate a transition. But my experience tells me this is for the best.

When I created BLT 10 years ago (before it was even named BLT), I was its staunchest advocate and champion. I built countless sites using it in Acquia Professional Services, and I even advocated for it at Drupal conferences. But if you look at those conference talks, you’ll notice I was advocating for other projects as well, such as the Lightning Distribution and DrupalVM.

Both of those projects are now EOL. Do I think I was wrong to advocate for them? Absolutely not. I had and still have the utmost respect for those projects and their creators. The reason I don’t use DrupalVM (not to pick on Jeff Geerling) has nothing to do with the quality of the project or the community around it. Rather, it’s because tools like DDEV and Lando have matured enough to replace it.

Similarly, I think open-source tools similar to BLT, as well as Acquia products, have matured to the point that for most use cases, BLT simply isn’t the best solution any more. Keep in mind that BLT for Drupal 7 actually predates the Composer 1.0.0 release, and Drush had only existed for a few years at the time. It’s incredible to consider how much Drupal and the PHP community as a whole has matured in that time.

Again, I say this as someone who has migrated a half dozen of my own sites away from BLT and been pleasantly surprised by how much nicer it is to work with native tooling such as Composer and Drush without BLT as an intermediary.

I also hope that this will be good for the community as BLT contributors refocus their efforts on tools like Composer and Drush and help to fill whatever feature gaps might still remain.

As always, I and Acquia will do whatever we can to support this transition and welcome any feedback on how to make it easier. Thanks for reading, and thanks to everyone for your support and contributions over the last 10 years.

from blt.

@danepowell Can we have more transparency around this decision? There is always frustration with sunsetting of a often used tool, but with more information it's easier to digest, respect and understand these decisions. In the last 3-4 years I've been working with Acquia platforms we have been consistently directed by Acquia to use the BLT tool. As such, we've built a decent sized library of custom commands on top of it which will have to migrate elsewhere. All this together does not build confidence in using Acquia tools in the future. I am also struggling to find a complete replacement for the customizations we have built on top of BLT, but I'll admit I have not had the time to investigate all the tools we'd need for feature parity in our BLT libraries yet.

from blt.

@joegl wonder if there is a place we can setup to start identifying and tracking useful tooling that replicates desirable BLT functionality that we'll be losing. For example, the artifact generation is IMO an industry leading feature that is slept on and I want to very much continue to use it. Maybe open a new Discussion thread in this project?

from blt.

@lpeabody have you tried acli push:artifact instead of BLT's artifact generation? It should produce nearly identical results and is overall easier to use since it automatically detects vendor dependencies to add to the artifact.

I would suggest breaking out discussions about replacing specific features and keep this thread focused on the EOL process itself.

Can we have more transparency around this decision?

I hear you. I'll have more to say on this shortly, let me collect my thoughts.

from blt.

Will we be able to run composer on Acquia Cloud? Or should we just run it locally to a separate folder and then commit that straight to the Acquia Git? What is the best practice around that? I looked at the "why you don't need BLT" article but it didn't really mention much about Composer, unless I'm missing it.

from blt.

@danepowell I have not but I'll keep that one handy for the future. Thanks.

from blt.

Good session from Drupalcon Pittsburgh on using Robo (which BLT is built on) to do automated workflows...

https://www.youtube.com/watch?v=tVBDSTEiboU

Thanks @dpagini I was looking at the same presentation earlier. Seems like what we'll have to do.

from blt.

@danepowell That was a great write-up, I really appreciate it and completely understand your thoughts on the matter. I have not set up BLT before -- only used and extended what is there, the majority of which are custom Robo commands. I would guess but can't know others are in the same position. dpagini shared a presentation I intend to watch on implementing Robo separately, however the suggestions in the article you put together don't include a replacement for Robo integration/implementation (from what I can tell). If you had suggestions and/or updated the article for that, I think it might help a lot. Thanks for your time and thorough response.

from blt.