done
Lets get a gitter?
Maybe a trello board would be good for roadmap?
@cal97g I think @ziirish is going to start working on the community bits and bobs (correct me if that doesn't include gitter @ziirish ). IMO, it would be worth using GitHub for the roadmap just to try and minimise the sprawl of different tools - but of course that's up for vote :) I'll check in again later on this evening :)
Couple of things related to this big rename @ziirish , @j5awry :
AUTHORS.rst is very out of date - do we keep it as is, update it or remove it? What shall we do with CHANGELOG.rst, I guess we'll start the versioning on this from 0 again, is it worth removing the change?
Change log*
As for
AUTHORS.rst. imho, it doesn't have any advantages over git shortlog --summary --numbered --email and is always outdated :)
Couple quick things -- remove Akamai from the copyright. I don't work there anymore (well, won't, as of Jan 17th), and I never made a code commit that's copyrightable.
Kill py2
I'm not quite understanding how the 2 packages things will work since we can only publish 1
I'm a fan of slack because I'm on it all the time. Gitter is fine, but since i don't live on it, i don't check as often as I should. I...hate zulip.
@j5awry project name on pypi != packages that it provides. For example, both https://pypi.org/project/jwt/ and https://pypi.org/project/PyJWT/ provides package with jwt name. https://github.com/python-restx/flask-restx/blob/master/setup.py#L78 this section can include whatever you want number of packages. usually, it inbcludes only one package that equals to project name on pypi, but there are a lot of cases that it is not true. ANother example is here, when setuptools.find_packages method is executed but without providing
exclude=['tests', 'tests.*']... there are a lot of projects on pypi that delivers tests package alone with their projects
@SteamBytes: hm... as far as I remember, 'packages' section of setup.py accepts a dict where key is name of package and value is path(or something like this?!). This means that several keys can map to one path. The hardest part is to distinguish whether it was import of 'flask_restx' or 'flask_restplus' to print deprecation message. Here we have to options. First one is adding parsing of call traceback to flask_restx.init to identify this. Another option is adding almost empty files into flask_restplus dir that duplicates names of public modules of flask_restx and include imports of flask_restx, so the code part will not be duplicated
Yeah, the
setup.py bit isn't so much the problem - it's how to manage the code between both packages. If there's no absolute imports within the package itself i.e. from flask_restplus.models import ... then in theory pointing both packages to the same flast_restx directory should work (not that I've verified this).
If possible, option 1 or something similar would be best IMO
As long as parsing that call traceback does not have a significant impact at runtime
I've put up a WIP PR for the renaming python-restx/flask-restx#2 @ziirish, @j5awry please take a look at the questions in the PR description regarding author name :smile:
I've got to sign off for tonight now, hopefully we'll have some answers to the questions I mentioned on python-restx/flask-restx#2 and I can get the great renaming of 2020 complete tomorrow :wink:
not yet
soon == by the end of the week
after that, we will work on a proper release as discussed here: noirbizarre/flask-restplus#743
i'm also using swagger and swagger ui
so the intent would be to make an operation that takes body parameters of a certain model, does something with those values, and then returns a serialised response to the client