Re: [Fab-user] What is the future vision of fabric/invoke?
On Fri, Apr 5, 2019 at 1:42 AM Jeff Forcier wrote: > Hi Mich, > > Thanks a lot for your detailed feedback; I appreciate the difficulty > you're going through. The development status has been in limbo since my > employer was acquired late last year, so I haven't had time to polish all > these rough edges. This ought to change in the near future now that I've > found new employment. > > I'm in the middle of a cross-country move this week and next, so I can't > be as detailed as I'd like, but some quick points: > This is already good to know. I had the feeling that the project seemed kind of stagnant. But knowing that you are still motivated to continue is a helpful piece of information. > > [The upgrade page] was not really helpful and very confusing. I ended > up perusing the API docs to find what I needed, but this still involved > some guesswork. > > I've got my own ideas for how to improve that page's usability, but I'd > love to hear about what you were expecting to find / what sorts of info (or > style of organization) would have helped you here. > This is really hard to answer as it is pretty much different for everyone. So what might be good for me might be useless for someone else. From the top of my head I'm wondering if it were possible to add some examples? And maybe explicitly mention that you accept PRs for such "old vs new" examples. I'd certainly be willing to share at least the simple tasks I have lying around. This might even open up the possibility for some minor review by the maintainers giving tips on how to do things more effectively with fabric-2 > > I now believe that the "fab" executable is useless for us and that we > could do everything with "invoke" and just import fabric connections in our > "tasks.py" file. > > The `fab` shim needs more work to avoid a lot of the rough edges (to be > understated) you've run into, but... > > > it does not seem that this is the intended way to do it. > > ... this isn't accurate - using Invoke as the main interface/framework and > then importing Fabric into that code *is* definitely a supported/intended > use case. (A major goal here was to be less opinionated and more just > providing building block APIs that advanced users can use however they > need, without us having to anticipate every use case.) > > I _do_ want to get to where v2's `fab` is more readily usable for folks > coming from v1, as well, but I suspect for now an intermediate-to-advanced > team would find more utility with the other approach. > Fair enough. Since I wrote my last mail I've moved more into the direction of using "invoke" as main task-runner and use the fabric API internally once I need to run stuff remotely. > > Dropping the concept of "roles" surprised me. > > Roles have NOT been dropped purposefully, they just haven't been migrated > yet - getting the lower level APIs set up (again, in the spirit of "let > advanced users build what they need instead of making them wait for higher > level stuff to get finished") was done first. > > The upgrading page should have a link to the issue or issues around > building a "v2" style functionality that fills the roles use case better > (mostly by bridging configuration to the Group class). If you didn't run > across that line, it's likely part of the previous issue re: searchability > of that page. > It may indeed be true that I've not come across this yet. Our use-cases are all really simple and don't need much of configuration. So, while the configuration system looks very powerful, it seems unnecessarily complex for our work. Note that we also use ansible to manage our servers, and the new complexity in fabric blurs the lines between ansible and fabric/invoke. We see fabric/invoke as a tool to automate common development tasks (like syncing the dev DB from the prod DB or setting up a clean development environment), while ansible is dealing with everything system related like ensuring DBs and users exist, privileges and so on. We *could* do all that in fabric/invoke, but in the end, ansible is better suited for those tasks, and we also have the sys-admin and developer roles separated. Ansible is used by the sys-admins while invoke/fabric is used by the devs. To make a long story short, we don't really need complex configurations. So this was just barely skimmed when I was reading the docs. > > Running local tasks does not behave as expected due to the way the > console and environment variables are handled. > > This feature area ought to be an overall upgrade to how it worked in v1, > so I'd definitely appreciate details here (if you posted them in another > thread, just let me know, as noted I have not had time to pay close > attention). It's possible you're running into things related to the v2 APIs > having more fine-grained 'levers' for you to tweak, not sure. > The most prominent example is visible in one of our "default" tasks called "run" that each project is supposed to have. For example, when running
Re: [Fab-user] What is the future vision of fabric/invoke?
Hi Mich, Thanks a lot for your detailed feedback; I appreciate the difficulty you're going through. The development status has been in limbo since my employer was acquired late last year, so I haven't had time to polish all these rough edges. This ought to change in the near future now that I've found new employment. I'm in the middle of a cross-country move this week and next, so I can't be as detailed as I'd like, but some quick points: > [The upgrade page] was not really helpful and very confusing. I ended up perusing the API docs to find what I needed, but this still involved some guesswork. I've got my own ideas for how to improve that page's usability, but I'd love to hear about what you were expecting to find / what sorts of info (or style of organization) would have helped you here. > I now believe that the "fab" executable is useless for us and that we could do everything with "invoke" and just import fabric connections in our "tasks.py" file. The `fab` shim needs more work to avoid a lot of the rough edges (to be understated) you've run into, but... > it does not seem that this is the intended way to do it. ... this isn't accurate - using Invoke as the main interface/framework and then importing Fabric into that code *is* definitely a supported/intended use case. (A major goal here was to be less opinionated and more just providing building block APIs that advanced users can use however they need, without us having to anticipate every use case.) I _do_ want to get to where v2's `fab` is more readily usable for folks coming from v1, as well, but I suspect for now an intermediate-to-advanced team would find more utility with the other approach. > Dropping the concept of "roles" surprised me. Roles have NOT been dropped purposefully, they just haven't been migrated yet - getting the lower level APIs set up (again, in the spirit of "let advanced users build what they need instead of making them wait for higher level stuff to get finished") was done first. The upgrading page should have a link to the issue or issues around building a "v2" style functionality that fills the roles use case better (mostly by bridging configuration to the Group class). If you didn't run across that line, it's likely part of the previous issue re: searchability of that page. > Running local tasks does not behave as expected due to the way the console and environment variables are handled. This feature area ought to be an overall upgrade to how it worked in v1, so I'd definitely appreciate details here (if you posted them in another thread, just let me know, as noted I have not had time to pay close attention). It's possible you're running into things related to the v2 APIs having more fine-grained 'levers' for you to tweak, not sure. > "put" no longer supports folders [...] I think this was noted on the upgrading page, but the recursive put() had an absolutely dismal utility-to-bug-surface ratio (esp given it's just us poorly reinventing functionality that native Unix tools have had for decades). Is there a reason you're not able to use things like tar.gz? My expectation is to make the 'ramp' to this easier (eg making it trivial for users to determine what native tools they have available - tgz, rsync, etc - or autoselection) without actually porting v1's bug-prone implementation. > I am wary of the fact that I *need* this kind of scaffolding for something that was much easier with fabric-1 As you can probably guess from my opening and the rest, this is (IMO) due almost entirely to the fact that I wanted to get v2 out into the world instead of waiting until it was "fully ready" (combined with unfortunate timing in my professional and personal life) and does _not_ reflect the intended final state of things. Building those kinds of scaffolding are exactly where I intend the core dev to go next. Best, Jeff On Thu, Apr 4, 2019 at 1:37 AM Michel Albert wrote: > Hi, > > In our development team we have been using fabric-1 as task runner for > many years and we are really happy with it. Initially we chose it for the > following reasons: > >- Being Python, we can transfer our development logic to our >task-runner as Python is our main development language >- Defining tasks is really easy and flexible >- It allowed us to create a library of shared tasks for the whole team >making definition of new fabfiles a breeze for our projects >- It "just worked" > > We are now planning to review and refresh our whole development process > and environment. The task runner is part of this. > As some preparation work and to gain experience I've tried to move some > personal projects to fabric-2 and ran into several problems: > >- The first hurdle was the "migrating to fabric-2" document. It was >not really helpful and very confusing. I ended up perusing the API docs to >find what I needed, but this still involved some guesswork. >- The split of "invoke" and "fabric" is confusing.
