Removed verify_exists from URLField for Django 1.5+ compatibility.

[lockhart]

This seems required (I am testing the same modification). How are you updating urls.py? The "deprecated patterns" need to be removed for django-1.5 or need to be updated to class-based view syntax. And what about versioning on feedjack? afaict the version number has not changed in years.

[rolo]

Heh, I backed away when I spotted that all the generic views needed updating as well :). I was on the lookout for a fork which was Django 1.5 compatible for an old project we've inherited. I see that there are a few different ones knocking around without a single one standing out as most likely to be maintained. I didn't look very carefully at any of them, but yours had the most recent commit. If I don't find one I'll upgrade one of them (yours if most suitable) myself, and will let you know.

On 6 August 2013 16:06, lockhart notifications@github.com wrote:

This seems required (I am testing the same modification). How are you updating urls.py? The "deprecated patterns" need to be removed for django-1.5 or need to be updated to class-based view syntax. And what about versioning on feedjack? afaict the version number has not changed in years.

— Reply to this email directly or view it on GitHubhttps://github.com/mk-fg/feedjack/pull/1#issuecomment-22185333 .

Rolo Mawlabaux Wildfish Ltd | http://wildfish.com

[lockhart]

I've been using this fork for a while. The cato-/dango-feedjack fork has been updated recently, but seems to have a different history (e.g. fields have been changed, the management/ area does not exist) even though it has some commits apparently related to django-1.5. Shall we ping each of these maintainers and see what they are interested in? mk-fg, are you here?

[mk-fg]

Here.

Still need to update my setup to django-1.5 myself, guess I'll see what needs fixing and test/merge the thing when I do, hopefully in the next few days.

[mk-fg]

Thanks for @cato- dango-feedjack mention btw, there's @allo- fork too. I've seen this one (and probably linked somewhere in the readme) before in third-party repo, but not on github.

allo- proposed merging changes (link) in the past, but with all the scm shuffle and re-imports I have all commits squashed or mangled here, so no easy merges now, alas.

Will look at new changes there, might be able to cherry-pick these.

[allo-]

yeah, we're working together to make some bigger changes, but at the moment there is very little progress, because of not having so much time. Planned is a new Updater, new responsive theme, support for endless-scroll and much more. We're already having the group feature and the new-since feature, which i coded some time ago.

[lockhart]

Not sure about the @allo- fork. I did notice with the @cato- fork that "shortname" became "slug"; perhaps that helps with convergence to conventions used in other packages? How about the "deprecated" paths in urls.py? I've removed them from my copy and if it is time to really remove them I can commit back those changes with a pull request (of course, this is a simple change). Any thoughts on versioning? I'd propose doing a versioned tag now, then possibly merging in other work, then updating release notes and tagging for 1.0. afaict the original developer is no longer active and it would be helpful to have a valid version number. Perhaps @allo- and @cato- can weigh in with the features in their forks and what should be merged in? I would assume that since your fork has a management/ directory that it has advanced at least in that area beyond the original code. I would guess that both @rolo and @lockhart would be happy to help with things; let us know.

[lockhart]

@allo- our responses crossed in the ether. I am just using the models and updating using the feedjack_update management method in the @mk-fj fork then using my own templates to display content. And I may not be configuring things fully for that whole "planet" thing; perhaps there is some background I am lacking to understand the use case or the analogy.

[allo-]

Maybe we should use some other platform to discuss this further ;). This bug is off-topic.

my fork is mostly a fork from cato repo, from our shared repository before. I have even commit access on cato-fork, and use my fork for unfinished stuff, to rebase and/or cherry-pick it later.

@lockhart: I am using feedjack as a feedreader, just for me, using the /since/DATE feature. The "since NOW" link seems to be broken at the moment, but the feature itself works just fine.

[lockhart]

So @allo- are you suggesting moving the merge topic elsewhere or just the discussion of how to use feedjack? Not sure what "this bug" refers to above. But in any case what platform would you suggest for this discussion? I'm looking forward to getting the best of feedjack merged back together. btw feedjack.org does not seem to respond; maybe it has been this way for a while?

[mk-fg]

Time for a feedjack mailing list? ;) To be honest, I don't think anything is offtopic in gh bugs after things like this or this. Maybe gh wiki would be a better place to post more long-term ideas?

Feedjack mostly works for me as a web-feedreader as well, mostly fixing occasinal breakages due to weird feeds and compatibility.

Wanted to make thing into an aggregator site on one job I've got lately. Got tired of webdev there quickly and abandoned it, but that's where py2.6 compat stuff came from, will look over commits there now, maybe something else useful can be cherry-picked.

I think /since/DATE got merged a while ago, but can't seem to find more relevant commit than 9a97906 atm, git-blame can probably help. I now use JS to track read stuff, which can probably use some work to be more generally useful.

A lot of stuff in this fork is related to me using it to aggregate/read feeds like reddit and hn in the past, hence a lot of kinda-raw hacks/hooks to filter and cross-reference content in a fairly high-volume feeds. Filters turned out to be useful for reading some post series (e.g. pick "LWN Weekly" from lwn.net rss), but maybe it's a lot of fairly incomprehensible bloat by now and cato/allo fork might be cleaner without it.

[mk-fg]

@lockhart I wonder why did you ask about versioning? I mean, given that it's not a pypi package and there are no releases as such, why would it be useful? When should it be bumped?

[mk-fg]

Thanks!

[mk-fg]

@rolo @lockhart Small note wrt django.views.generic:

Apparently django.views.generic.simple.redirect_to just got replaced with class-based django.views.generic.RedirectView in 1.5, so updated wrapper in feedjack.views and urls.py to use it in b27d8aa without dropping any old stuff.

It probably can be dropped (iirc "Long-ago deprecated" links were marked as such even in original svn/hg repo), but meh - easy enough to fix ;)

[allo-]

I think i may have used redirect_to and direct_to_template in my views. If your find them, django 1.5 has http.redirect and shortcuts.render. direct_to_template had the advantage, that it had a request-context, but this is the new default for render.

[rolo]

Sorry only just got a chance to get to this. My use case is that I'm upgrading a project we've taken on with an old version of feedjack. I'm not particularly attached to it, but just wanted something 1.5 friendly. Happy to help out if needed, although was also going to investigate if it might be best to switch to django-planet, as I gather that's where most of the feedjack users went.