Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is this project abandoned? #262

Open
gordalina opened this issue May 2, 2024 · 6 comments
Open

Is this project abandoned? #262

gordalina opened this issue May 2, 2024 · 6 comments

Comments

@gordalina
Copy link

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
Copy link

elridion commented May 2, 2024

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
Copy link
Author

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
Copy link
Contributor

inooid commented May 2, 2024

@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
Copy link

elridion commented May 2, 2024

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
Copy link
Author

@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
Copy link

elridion commented May 2, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants