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
Remove unnecessary crud from werkzeug.contrib #4
Comments
The question is what do we want to be werkzeug.contrib? Should it only contain wsgi related stuff or should it contain helpers for web development? If it's the first one (only wsgi-related helpers) then werkzeug.contrib.cache and contrib.atom should go away. Another question: is iterio even used widely, what was it's purpose? It depends on greenlet and seems to be the only part that does not even work without a external dependency. |
iterio should go into a separate PyPI package. Maybe the same should be done for cache, not sure yet. The modules from contrib I use are securecookie and cache. I don't think I ever used anything else from there. We could do a poll and ask what people are using enough that it's worth having in Werkzeug itself. Cache however lacks support for newer memcache adapters, so if it sticks, it needs an updated interface. |
Fixed remaining iterating-related stuff.
Cache is pretty well-maintained now, but i'd like to get it into a separate pkg anyway. The only module which really should stay is |
I wonder if we should move even more modules into separate packages, even though they are directly relevant to Werkzeug. An example would be |
i like the idea, but it needs some preparation and thougts |
I could be interested in helping out here, but would obviously need some decisions being made here. One idea would be extract some parts to external packages, i.e. We could for instance include these packages as dependencies in Werkzeug for a while and alias them in their existing locations for backwards compatibility, while emitting deprecation warnings about their future removals. |
sounds like a good plan to me, @mitsuhiko @untitaker do you agree? in case the others agree i propose providing @asteinlein with a repo under pallets for werkzeug-cache as a starting point and using werkzeug_cache as potential module name |
Agreed! Will set up a repo later. IIRC somebody already forked Werkzeug's profiler middleware into a new package. On Fri, May 27, 2016 at 01:59:58AM -0700, Ronny Pfannschmidt wrote:
|
IMO we should have one repo with a collection of useful middlewares, i.e. a
werkzeug-middleware, since many use cases are useful to provide defaults
for. Having multiple repos for different middlewares seems overkill to me.
Just my 2c though. :)
|
Middlewares will require more discussion, which ones to keep in Werkzeug and which not. The things that IMO definetly can be factored out are:
|
Let's start with @asteinlein I've added you as a collaborator to werkzeug-cache, @RonnyPfannschmidt you're a member anyway. |
Oh, I forgot that |
|
+1 on these:
-1 on urls Two reasons for this: a) i don't want to start having tiny dependencies everywhere. This is a huge maintenance hurdle and I keep learning this over and over at Sentry. Secondly because it's not even an entirely correct implementation of URLs. |
@mitsuhiko I was proposing |
@untitaker why is the repo (https://github.com/pallets/werkzeug-cache) deleted? |
@lepture i cannot remember but i think the transition was not properly coordinated, people still submitted PRs |
@untitaker I'm closing issues related to cache. #1249 I'll make a separated repo in next week. |
I added cards for all the |
I didn't add a card for |
Things I marked as "discuss, probably remove":
If we're +/-0 on any of these, we should prefer adding a deprecation notice. If people report they're still using something, we can always reconsider the deprecation before 1.0. |
Marking this for 0.15 to deprecate everything that needs to be. We can have a separate task to remove deprecated code for 1.0, which will include more than this. |
Some things ended up in contrib that really shouldn't have been there.
The text was updated successfully, but these errors were encountered: