8000 Towards 1.0 · Issue #52 · flask-api/flask-api · GitHub
[go: up one dir, main page]
Skip to content

Towards 1.0 #52

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.

Sign up for GitHub

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

Jump to bottom
Closed
tomchristie opened this issue Mar 21, 2016 · 14 comments
Closed

Towards 1.0 #52

tomchristie opened this issue Mar 21, 2016 · 14 comments
Labels
question

Comments

@tomchristie
Copy link
Contributor

I've been doing some preliminary work on a new Flask API framework. Given that I've never maintained Flask-API, and it's only ever been a very weak port of a few bits of REST framework, I'm strongly considering using this project for the latest work, and releasing it as a 1.0 version.

I'm really pleased with the incoming work, which is super simple, but features automatic client libraries & command line tool, plus schema generation in a nice & agnostic way (so, eg provide Swagger, API Blueprint, or any other schema type documentation out of the box)

I figure it's worth raising the issue here to see how folks would feel about an incompatible 1.0 release, if it was something that was actually going to push things forwards and be a release that I was actually using and significantly invested in for a change.

Any thoughts?
@tomchristie tomchristie changed the title New version Towards 1.0 Mar 21, 2016
@tomchristie
Copy link
Contributor Author

This has been taking a bit of a different tack.
Working towards something here: http://github.com/tomchristie/api-star
Actually it's cross-framework (Right now both Flask + Falcon) so unlikely it'd make sense for it to be presented as "Flask API".
Still a work in progress ATM.

@jacebrowning
8000 Copy link
Member

This looks interesting! When api-star "stabilizes", will there be any reason to recommend using flask-api on new projects?

@tomchristie
Copy link
Contributor Author

Not from my POV, no.

@tomchristie
Copy link
Contributor Author

An alternative tack might be to focus on taking the api-star work into this project and just focus on a Flask based framework, rather than multi-framework.
That might be a simpler sell, although a bit less flexible.

@jacebrowning
Copy link
Member

IMO flask-api is sitting on a pretty good name, while api-star's purpose is not obvious until looking into the README. Could flask-api become a thin wrapper around api-star?

@tomchristie
Copy link
Contributor Author

Sounds like that could be a good approach

@tomchristie
Copy link
Contributor Author

@jacebrowning I think your suggestion is probably the best way forward.

Main questions around that will be how to best present the documentation for each, given functionality split across two packages.

@jacebrowning
Copy link
Member
jacebrowning commented Apr 22, 2016 •
edited
Loading

@tomchristie I think it depends on what kind of userbase breakdown you're expecting. What percentage of users want to use api-star with Flask vs. Falcon? Will api-star support additional frameworks? Will you release thin wrappers around api-star for each of these frameworks?

I see two options:

  • Heavily document flask-api as if all the functionality is contained therein; sparsely document api-star
  • Heavily document api-star including a page for each framework (similar to http://webargs.readthedocs.org/en/latest/framework_support.html); sparsely document flask-api and point to the dedicated page in the api-star docs

@jredd
8000 Copy link
jredd commented Jul 28, 2016

If I can be of assistance in getting the framework to 1.0, however you guys decided to execute it, I'd love to help out in achieving that goal.

@tomchristie
Copy link
Contributor Author

Thanks! I'll aim to update this ticket if and when work resumes. Slightly on back burner for me right now, but it will pick up again at some point.

@jacebrowning jacebrowning mentioned this issue Apr 6, 2017
Merged
@tomchristie
Copy link
Contributor Author

Things from my side have gradually progress, and http://github.com/tomchristie/apistar is now certain to be where I put my "not Django" API time into. It's not impossible that it could have Flask integration as an option at some point, but it's probably more likely that it'll strike out on it's own. (Ideally with both SQLAlchemy and Django ORM backends becoming available as it progresses)

I'd probably suggest that we think about transferring ownership of this repo to @jacebrowning, or some suitable org that I'm not involved in.

That change could also be made alongside a 1.0 release if deemed appropriate?? (Would be a good point at which to make that switch)

@jacebrowning
Copy link
Member

If the repository was transferred, could it retain the name Flask-API?

Nowadays, I view this library as a bare-bones "API framework" for Flask. It doesn't insist on any particular style, but includes enough functionality to make Flask views return API responses with minimal boilerplate. As far as my personal uses are concerned, this library is ready for 1.0

@tomchristie
Copy link
Contributor Author

If the repository was transferred, could it retain the name Flask-API?

Yup

@jacebrowning
Copy link
Member
jacebrowning commented Apr 7, 2017 •
edited
Loading

I'm going to open a new issues to see if anyone else has options on transferring the repository: #76

@jacebrowning jacebrowning mentioned this issue Aug 13, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@tomchristie @jacebrowning @jredd
0