search

BlakeWilliams / Elixir-Slack

Slack real time messaging and web API client in Elixir
MIT License
674 stars 182 forks source link

Is this project abandoned? #262

Open gordalina opened 6 months ago

gordalina commented 6 months ago

I'd be happy to help contribute/maintain the project if so, if not then I could start a fork to integrate new changes.

elridion commented 6 months ago

The issue with this project seems to be two fold. But imho there is some work to be done to keep it maintained.

The current way the code is generated seems to be somewhat broken. The code for this project is generated using a json source supplies by slack. That itself seemed to be abandoned, so I reached out so Slack last year resulting in them archiving the repository.

So going forward that dependency has to be substituted. Some ruby packages seem to have run into similar issues so some folks over there build this which could come in handy. Another option would be to use the Open Api specs slack has somewhere?! - at least the SlackDeveloperTools bot says that its powered by them but I was unable to find them (maybe out of pure stupidity).

tl;dr the approach of this project is smart and worth saving but there is work to be done.

gordalina commented 6 months ago

Slack's node sdk package seems to be dependent on slack's java client which is itself just a dump of json logs. I also found a spec https://api.slack.com/specs/openapi/v2/slack_web.json which I think its what the SlackDeveloperTools is using as the spec is outdated and the developer tools are also outdated.

Maybe @episod has some knowledge about updated openapi specs that we don't?

The slack-ruby's api-spec project looks promising as a source dataset. I've also found that @inooid has built a mix task to generate the API docs and tried to update the docs in #255. I ran the task locally and it spit out an updated list of API endpoints.

My main concern is that I don't see the author replying/merging in code and a number of people wanting to have an updated version of the library. One way this can be solved is to either add more maintainers to this project, or fork it off and release a new one.

Happy to discuss on how that can be achieved and help moving things forward.

inooid commented 6 months ago

@gordalina The mix task that I wrote is nasty and scrapes/parses their public API docs, but since they have OpenAPI specs (now) this should probably be the fastest way of achieving this.

As much as I love the meta programming approach of this project, if the maintainer can't find the time to maintain it, it might be easier to use something like: https://github.com/OpenAPITools/openapi-generator for the time being or take the effort to fork/start a new project.

I appreciate the effort to kickstart the conversation 👍

elridion commented 6 months ago

The solution I had in mind was to adapt the current project or to create a new one based no the work done by the ruby folks, but again this depends on the current maintainer. But using the ruby scraping results one would be able to solely write the meta programming stuff without the hassle of having to write the scraping logic too.

gordalina commented 6 months ago

@gordalina The mix task that I wrote is nasty and scrapes/parses their public API docs, but since they have OpenAPI specs (now) this should probably be the fastest way of achieving this.

Where have you seen openapi specs? all I've seen are outdated.

The solution I had in mind was to adapt the current project or to create a new one based no the work done by the ruby folks, but again this depends on the current maintainer.

I think adapting the current project would be ideal as it would be easier for people to migrate to the new one (if they wished to do so).

It could follow what elixir-waffle/waffle did with stavro/arc, where they forked it into a new github organization. We could follow on their footsteps.

Again, this is assuming that this project doesn't have active maintainers, as best would be to keep this one going.

elridion commented 6 months ago

@gordalina I asked @BlakeWilliams about this, the same time I contacted Slack about their abandoned api specs and from what I understood, and what seems to be the case considering the amount of open pull requests, he has no intentions of spending time making improvements to this project. But I am very much interested in @BlakeWilliams perspective on all of this.