Re: [Twisted-Python] SMB server component for twisted
> On May 14, 2020, at 5:23 PM, Wilfredo Sánchez Vega > mailto:wsanc...@wsanchez.net)> wrote: > On May 7, 2020, at 12:48 AM, Glyph > mailto:gl...@twistedmatrix.com)> wrote: > > > > If you want to include it in Twisted itself, your best bet is to actually > > develop it within twisted, as a series of small contributions, rather than > > as one gigantic one-shot one. Contributions over, say, 400 lines, take > > exponentially longer to review. > > > > Developing it within Twisted will make things go slower; you'll need to get > > everything code reviewed, you'll need to support multiple versions of > > Python (no py2 any more, but py3.5 is still pretty old), you'll have to > > have full test coverage from the get-go. But doing these things from the > > start is much easier than trying to retrofit them. > > > > I actually think that this would be a pretty good fit for Twisted, in the > > same way that it's been a benefit to have Conch maintained alongside the > > rest of Twisted. I can see you're developing things very much in line with > > Twisted's architecture (using cred for authentication, a realm interface, > > etc) and you've voiced this interest, so it would be great to have you > > along! > I think it's great to get an SMB implementation in the Twisted org, but why > would we even consider adding something like this to the main Twisted > project? Just practically speaking, we've tried both approaches, and (very broadly generalizing) this one works and the other one doesn't. Separate projects that have been adopted from outside after they gained some traction are doing okay (i.e. Treq and Klein, some of the most popular applications for Twisted). But others (txacme) are suffering from a lack of maintenance and still others (ldaptor) just have a largely non-overlapping community and hardly benefit at all from org membership. And as you've noted, even the ones doing their best often want for reviews for far longer than Twisted's own latency. > The main repo is large, and including Twisted in your project brings along > far more functionality than you are likely to use, and packages are a fine > way to get the functionality you want, so what's the logic for including a > new thing in Twisted proper? Abstractly you make a plausible case. Concretely we tried to start splitting things up on the axes of protocol support and it just made a giant mess and created lots of overhead for the project. Modern infrastructure makes this slightly easier (last time we tried to start this process we didn't have a Github or a Travis), but not much easier. And even modern, better infrastructure leads to an avalanche of tedium as we copy CI configuration back and forth endlessly, replicating lessons that we learn about travis, and azure, and codecov, and (ad nauseam) Even in the abstract case though there’s a question of what twisted “is” and on what axes it should be split up. I think splitting up by protocol was largely a mistake, but splitting some of the really low level core stuff out (towncrier, automat, and hopefully filepath and deferred) has been pretty successful and worthwhile. Particularly in a post-asyncio world, the core event loop isn’t super interesting and the broad protocol support is the appeal. So even in the abstract case, there’s a case to be made that twisted is a bunch of implementations and interfaces for wire protocols that involve navigating hierarchies of things (DNS, HTTP, IMAP, SFTP) and SMB fits right in there. > You cite Conch above, where I'd actually argue that Conch should be moved to > a separate repo. Am I crazy? Not crazy, there's a valid case to be made, but Conch has received a tremendous amount of routine maintenance keeping it up to date with Twisted and Python API evolution by members of the project who would almost certainly otherwise not bother, just to keep the test suite going and the project as a whole integrated. This allows it to remain viable for the much smaller number of SSH-specific contributions that come along. > That said, a counter argument is that projects in the Twisted org suffer > greatly from poor participation and strict development rules, resulting in > glacial progress. It's not unusual for me to have a PR take 6 months to a > year to get a review (I have two right now that have been waiting since > November), and perhaps such PRs would get some attention in the main repo. > But I think that's an unfortunate way to address that problem. This is just a natural consequence of affordances provided by the tooling we presently have. Personally I look at the global queue of pull requests across all these projects and it's kind of exhausting. I don't think many other people do. Case in point: how many ldaptor or txacme reviews have you done since November? This is not to throw any shade; I’m not saying you should have, but it illustrates that right now, separate repos
Re: [Twisted-Python] SMB server component for twisted
On May 7, 2020, at 12:48 AM, Glyph wrote: > > If you want to include it in Twisted itself, your best bet is to actually > develop it within twisted, as a series of small contributions, rather than as > one gigantic one-shot one. Contributions over, say, 400 lines, take > exponentially longer to review. > > Developing it within Twisted will make things go slower; you'll need to get > everything code reviewed, you'll need to support multiple versions of Python > (no py2 any more, but py3.5 is still pretty old), you'll have to have full > test coverage from the get-go. But doing these things from the start is much > easier than trying to retrofit them. > > I actually think that this would be a pretty good fit for Twisted, in the > same way that it's been a benefit to have Conch maintained alongside the rest > of Twisted. I can see you're developing things very much in line with > Twisted's architecture (using cred for authentication, a realm interface, > etc) and you've voiced this interest, so it would be great to have you along! I think it's great to get an SMB implementation in the Twisted org, but why would we even consider adding something like this to the main Twisted project? The main repo is large, and including Twisted in your project brings along far more functionality than you are likely to use, and packages are a fine way to get the functionality you want, so what's the logic for including a new thing in Twisted proper? You cite Conch above, where I'd actually argue that Conch should be moved to a separate repo. Am I crazy? That said, a counter argument is that projects in the Twisted org suffer greatly from poor participation and strict development rules, resulting in glacial progress. It's not unusual for me to have a PR take 6 months to a year to get a review (I have two right now that have been waiting since November), and perhaps such PRs would get some attention in the main repo. But I think that's an unfortunate way to address that problem. -wsv ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] [RFC] Drop support for Python 3.5 sometime after May 2021?
> On May 14, 2020, at 3:55 AM, Amber Brown wrote: > > > > On Thu, 14 May 2020, at 16:54, Glyph wrote: >> >>> $ /usr/bin/python3 >>> Python 3.7.3 (default, Apr 7 2020, 14:06:47) >>> [Clang 11.0.3 (clang-1103.0.32.59)] on darwin >>> Type "help", "copyright", "credits" or "license" for more information. >> import sys >> sys.executable >>> '/Applications/Xcode.app/Contents/Developer/usr/bin/python3' >> > > wow thanks I hate it ITYM 'Wow thanks I hate it.app' -g ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] [RFC] Drop support for Python 3.5 sometime after May 2021?
On Thu, 14 May 2020, at 16:54, Glyph wrote: > > > $ /usr/bin/python3 > > Python 3.7.3 (default, Apr 7 2020, 14:06:47) > > [Clang 11.0.3 (clang-1103.0.32.59)] on darwin > > Type "help", "copyright", "credits" or "license" for more information. > > >>> import sys > > >>> sys.executable > > '/Applications/Xcode.app/Contents/Developer/usr/bin/python3' > > >>> wow thanks I hate it > -g > > ___ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python > ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] [RFC] Drop support for Python 3.5 sometime after May 2021?
> On May 13, 2020, at 11:13 PM, Amber Brown wrote: > > On Thu, 14 May 2020, at 16:09, Hynek Schlawack wrote: >> >> >>> On 14. May 2020, at 07:04, Amber Brown (hawkowl) >>> wrote: >>> >>> - MacOS doesn't ship a Python 3, but homebrew/python.org offer 3.8 easily. >> >> FWIW this is not true anymore. Catalina comes – for all its faults – >> with Python 3.7: >> > > *puts fingers in ears* sorry I can't hear you, I'm in my happy place where I > don't have to think of software in ".framework" folders la la la la Oh hawkowl. Either you die an a.out, or you live long enough to become a .dylib > But, it's good to know, anyway. Unfortunately it's only kind of true! $ /usr/bin/python3 Python 3.7.3 (default, Apr 7 2020, 14:06:47) [Clang 11.0.3 (clang-1103.0.32.59)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.executable '/Applications/Xcode.app/Contents/Developer/usr/bin/python3' >>> You can also get one from /Library/Developer/CommandLineTools/usr/bin/python3 if you do `xcode-select --install` but it's not present in the macOS base image and you can't use it from applications. -g ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] [RFC] Drop support for Python 3.5 sometime after May 2021?
On Thu, 14 May 2020, at 16:09, Hynek Schlawack wrote: > > > > On 14. May 2020, at 07:04, Amber Brown (hawkowl) > > wrote: > > > > - MacOS doesn't ship a Python 3, but homebrew/python.org offer 3.8 easily. > > FWIW this is not true anymore. Catalina comes – for all its faults – > with Python 3.7: > *puts fingers in ears* sorry I can't hear you, I'm in my happy place where I don't have to think of software in ".framework" folders la la la la But, it's good to know, anyway. - Amber ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] [RFC] Drop support for Python 3.5 sometime after May 2021?
> On 14. May 2020, at 07:04, Amber Brown (hawkowl) > wrote: > > - MacOS doesn't ship a Python 3, but homebrew/python.org offer 3.8 easily. FWIW this is not true anymore. Catalina comes – for all its faults – with Python 3.7: ❯ /usr/bin/python2 WARNING: Python 2.7 is not recommended. This version is included in macOS for compatibility with legacy software. Future versions of macOS will not include Python 2.7. Instead, it is recommended that you transition to using 'python3' from within Terminal. Python 2.7.16 (default, Feb 29 2020, 01:55:37) [GCC 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.29.20) (-macos10.15-objc- on darwin Type "help", "copyright", "credits" or "license" for more information. >>> ^D ~ took 6s ❯ /usr/bin/python3 Python 3.7.3 (default, Apr 7 2020, 14:06:47) [Clang 11.0.3 (clang-1103.0.32.59)] on darwin Type "help", "copyright", "credits" or "license" for more information. ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
