6 ms·

Rewriting the Slack Python SDK

50 points by reinhardt 7y ago

kissgyorgy 7y ago
Don't bother, I have my own based on asyncio with Real Time API support, pagination and everything. If people interested separating this to it's own package, let me know! https://github.com/kissgyorgy/gerrit-slack-bot/blob/master/slack.py https://github.com/kissgyorgy/gerrit-slack-bot/blob/master/s...
- marcinzm 7y ago
  >Don't bother Why not? Theirs has better support behind it and supports everything you listed (RTM api, pagination, async, etc.).
  - kissgyorgy 7y ago
    It's API is actually terrible and has bugs which mine don't.
    - marcinzm 7y ago
      And again, you make statements and don't provide any data to back them up. If there's issues with their API which yours doesn't have then describe or list them. edit: You also conveniently change your argument once I point out the previous one doesn't hold up.
    - orf 7y ago
      yours just has a bunch of print statements, several FIXME's, some weird choices (throwing an ApiError in one case but just printing the error in another), random things like a half baked Emoji enum (make this dynamic) and isn't a library you can pip install. The code is quite clean though.
dijit 7y ago
They're rewriting with py3 in mind? Excellent, unlike removing a headphone jack; I consider this truly courageous.
MobileVet 7y ago
It still amazes me that Slack, with its infinite resources, hasn’t built native clients. One code base is nice and all, but man I loathe the Electron app.
- outime 7y ago
  I want to remind that Slack is not a simple chat app - it should not be oversimplified, because it has tons of added functionality. Not that you said that but it's easy to fall into that trap. That being said, creating a native app for 2-3 (depends if you include Linux) different OS with completely different frameworks and maintaining feature parity between them involves a lot of specific knowledge and (probably) separate teams. Even if you have a good budget ("infinite resources" is quite arguable) it adds a lot of complexity to something that already has it. All of that just to somehow have a bit more fluent client (but probably much less polished). The cost for this change would be very, very difficult to justify.
  - BubRoss 7y ago
    > That being said, creating a native app for 2-3 (depends if you include Linux) different OS with completely different frameworks and maintaining feature parity between them involves a lot of specific knowledge and (probably) separate teams. Why do people believe this? It could be written once in C++ using Qt, Juce, or Fltk and be blazingly fast. This has been done thousands of times over the last few decades. Where does this myth come from?
    - dmitriid 7y ago
      > It could be written once in C++ using Qt, Juce, or Fltk and be blazingly fast. So, it was written once using Electron and is sufficiently fast. > This has been done thousands of times over the last few decades. Where does this myth come from? There are surprisingly few cross platform apps written using these technologies that are fast, functional and have any degree of visual polish.
      - 7y ago
underyx 7y ago
I was trying to update my all-in-one duct tape Docker image[0] yesterday and was surprised to see that they ramped up the complexity so much for this release, I had to install a new C library just to be able to compile a dependency of a dependency they added.[1] [0]: https://github.com/underyx/url https://github.com/underyx/url [1]: https://github.com/underyx/url#5-2019-05-31 https://github.com/underyx/url#5-2019-05-31
- josteink 7y ago
  Let me get this straight. All this shit, not for a full app, but for a premade REST API wrapper? Seriously? Sounds just about as terrible as the C#/.Net Azure SDKs.
- omni 7y ago
  C extensions are a pretty common thing in the Python ecosystem, you're making this sound a lot more drastic than it is
  - underyx 7y ago
    They are, but not for an API wrapper.
zild3d 7y ago
Happy about this, writing a slack app/bot with the old SDK was often opaque sc.api_call() with strings for the specific API (there are dozens, each with different inputs) always felt like a temporary ducttape SDK
maxdo 7y ago
I've done the integration with 10+ different chat API's, Slack is one of the most complicated ones and the one that ignored the whole industry at all. The way it is done is totally alien to any experience you might have with other chat sdk's before.

50 points by reinhardt 7y ago

Don't bother, I have my own based on asyncio with Real Time API support, pagination and everything. If people interested separating this to it's own package, let me know! https://github.com/kissgyorgy/gerrit-slack-bot/blob/master/slack.py https://github.com/kissgyorgy/gerrit-slack-bot/blob/master/s...

marcinzm 7y ago
>Don't bother Why not? Theirs has better support behind it and supports everything you listed (RTM api, pagination, async, etc.).
- kissgyorgy 7y ago
  It's API is actually terrible and has bugs which mine don't.
  - marcinzm 7y ago
    And again, you make statements and don't provide any data to back them up. If there's issues with their API which yours doesn't have then describe or list them. edit: You also conveniently change your argument once I point out the previous one doesn't hold up.
  - orf 7y ago
    yours just has a bunch of print statements, several FIXME's, some weird choices (throwing an ApiError in one case but just printing the error in another), random things like a half baked Emoji enum (make this dynamic) and isn't a library you can pip install. The code is quite clean though.

dijit 7y ago

They're rewriting with py3 in mind? Excellent, unlike removing a headphone jack; I consider this truly courageous.

MobileVet 7y ago

It still amazes me that Slack, with its infinite resources, hasn’t built native clients. One code base is nice and all, but man I loathe the Electron app.

outime 7y ago
I want to remind that Slack is not a simple chat app - it should not be oversimplified, because it has tons of added functionality. Not that you said that but it's easy to fall into that trap. That being said, creating a native app for 2-3 (depends if you include Linux) different OS with completely different frameworks and maintaining feature parity between them involves a lot of specific knowledge and (probably) separate teams. Even if you have a good budget ("infinite resources" is quite arguable) it adds a lot of complexity to something that already has it. All of that just to somehow have a bit more fluent client (but probably much less polished). The cost for this change would be very, very difficult to justify.
- BubRoss 7y ago
  > That being said, creating a native app for 2-3 (depends if you include Linux) different OS with completely different frameworks and maintaining feature parity between them involves a lot of specific knowledge and (probably) separate teams. Why do people believe this? It could be written once in C++ using Qt, Juce, or Fltk and be blazingly fast. This has been done thousands of times over the last few decades. Where does this myth come from?
  - dmitriid 7y ago
    > It could be written once in C++ using Qt, Juce, or Fltk and be blazingly fast. So, it was written once using Electron and is sufficiently fast. > This has been done thousands of times over the last few decades. Where does this myth come from? There are surprisingly few cross platform apps written using these technologies that are fast, functional and have any degree of visual polish.
    - 7y ago

underyx 7y ago

I was trying to update my all-in-one duct tape Docker image[0] yesterday and was surprised to see that they ramped up the complexity so much for this release, I had to install a new C library just to be able to compile a dependency of a dependency they added.[1] [0]: https://github.com/underyx/url https://github.com/underyx/url [1]: https://github.com/underyx/url#5-2019-05-31 https://github.com/underyx/url#5-2019-05-31

josteink 7y ago
Let me get this straight. All this shit, not for a full app, but for a premade REST API wrapper? Seriously? Sounds just about as terrible as the C#/.Net Azure SDKs.
omni 7y ago
C extensions are a pretty common thing in the Python ecosystem, you're making this sound a lot more drastic than it is
- underyx 7y ago
  They are, but not for an API wrapper.

zild3d 7y ago

Happy about this, writing a slack app/bot with the old SDK was often opaque sc.api_call() with strings for the specific API (there are dozens, each with different inputs) always felt like a temporary ducttape SDK

maxdo 7y ago

I've done the integration with 10+ different chat API's, Slack is one of the most complicated ones and the one that ignored the whole industry at all. The way it is done is totally alien to any experience you might have with other chat sdk's before.