Awareness of similar project? about django-app-namespace-template-loader HOT 16 CLOSED

@benjaoming Branch created

https://github.com/Fantomas42/django-app-namespace-template-loader/tree/feature/django-apptemplates

from django-app-namespace-template-loader.

No, I don't think this is a good idea. I've taken over that project on Bitbucket, because it was unmaintained and I'm using it in my projects. The main advantage of Julien's app is the existence of tests. (With a remarkable test coverage, as we are used to see from him all times.)

django-apptemplates is around for ages, it has a prominent history, the codebase is small (smaller than django-app-namespace-template-loader's, that's its strong point) and I'm not aware of complaints that it may not work for any Python/Django combination. But still, it has no tests. Think of it.

Either you trust the app (blindly), or you contribute tests ⭐ to the project. Or you better use Julien's app.

(:star: In this case I would even consider moving the project to GitHub, if that makes things easier.)

from django-app-namespace-template-loader.

Hello all,

I know that django-apptemplates exists and the team is pretty quick for updating stuff :)

It's my fault for the late updates...

Each projects are working with different approaches, so why not having the choice ?

Regards

from django-app-namespace-template-loader.

I'm a big fan of @Fantomas42 's work so the intention of this comment was to join forces and free up resources, not any kind of critique of neither projects, although I also slightly favour "django-app-namespace-template-loader", except for it's ridiculously long name :P

I like that Julien has maintained the same template {% extends %} syntax as app_templates because it means that you can switch between the two projects seamlessly.

But it also makes it difficult to write clear dependency specs. If my app depends on django-apptemplates and it's installed together with an app that depends on another one, then sure enough both will be installed and just one of them will be activated, depending on user's project settings.

But @bittner and @Fantomas42 what do you mean about different approaches? If Django 1.9 support is added to django-app-namespace-template-loader, can this CI tested and improved codebase not just replace django-apptemplates and then we can discuss the best approach in just one forum?

The larger goal IMO should be to have this loader and its syntax in something like django.template.loaders.app_directories.PrefixLoader and at some point have it be part of django.template.loaders.app_directories.Loader. While having two projects with the same goal indicates a big interest, it also fragments the development and discussion of an approach to introduce it in mother Django :)

AFAIK, this is also an issue in Jinja2, since template discovery happens the same way.

Best,
Ben

from django-app-namespace-template-loader.

Lol 👍 for the ridiculously long name.

Note support for Django1.9 has been added on the freshly published release.
So you can try a replacement...

But you are right, we should focus our efforts on one implementation.

from django-app-namespace-template-loader.

Since Django 1.9 is a fact for django-app-namespace-template-loader, then there isn't really any harm done in replacing coming versions of django-apptemplates.

I would propose renaming this project and releasing it to PyPi as django-apptemplates, meaning that @Fantomas42 gets access to upload to the already registered PyPi project. The next release should merge in their version scheme, making it a major version bump, django-apptemplates 2.0 with appropriate license changes and references pointing to this repo (renamed to django-apptemplates).

Then the Bitbucket repo doesn't have to be migrated, it can just remain stale.

Does it sound doable? :)

from django-app-namespace-template-loader.

OMG, I couldn't care less. And it wouldn't be the first package on PyPI that I make @Fantomas42 package index owner, correct Julien?

Honestly, the only preference I have is that the package name is short and sweet (because beautiful is better than ugly). I think that's why I took over and updated the other package even knowing this package existed. If only the community would solve that problem and we could lean back and watch. If only I could be as lazy as Linus Torvalds, because others maintained packages I need (in a way I could continue to love them). Seriously, I don't want to maintain packages, I want them to work.

Technically, the ancient Roman django-apptemplates still runs older Django versions. But I'm not sure if we should care at all.

from django-app-namespace-template-loader.

I will do the devil's advocate,
just renaming the package will not add any value to the package, except for your laziness of typing 17 more characters.

>>> len('django-app-namespace-template-loader') - len('django-apptemplates')
17

Or less if you copy'n'paste the package name :)

And in another side, it may lead to confusion for maintainers of projects using these apps.
Several years ago, this mess happened more or less on django-tagging... It was a great moment.

Like I said before, each projects are working but with different approaches in the codebase, so why not having the choice ? It's like the principle of parallel-evolution, a need appears in different places and each place provides his own solution for the same need. But this does not question the fact that we should now focus ours efforts on only one implementation for the future.

PS: Beautiful is better than ugly, is a good quote (even if your not a designer, it's common sense), but I prefer the next quote, Explicit is better than implicit. That's why such a long name.

from django-app-namespace-template-loader.

(Oh yeah, and that was it, django-tagging. You're package index owner of that, finally. We made that possible, and this was a good move because the "original" package was unmaintained.)

I agree (on the parallel-evolution). 👍

As a user I would probably rebel. Joining forces was always an important topic for me (as a user when looking at projects; django-tagging is an example), but there are no forces to join (because I hope not to have to touch the package again). Seems like it's just about the name.

from django-app-namespace-template-loader.

@bittner this is an example of when it's not just the name -> https://github.com/django-blog-zinnia/zinnia-theme-bootstrap/pull/18/files/c15c6a99b1d94888ec201ba45fd2bb2c6701bb75#r61857531

@Fantomas42 do you want to create a separate branch on django-app-namespace-template-loader called django-apptemplates and then we can work out the name refactor in there? I'm willing to lend a hand :)

from django-app-namespace-template-loader.

Great, I'm on this! It's in my TODO, gonna have a look one of the next days.. will create a PR into the new feature branch when ready.

from django-app-namespace-template-loader.

Let me just mention that I've moved django-apptemplates to GitHub in the meantime, and we've added integration tests thanks to a few users pushing for a solution. Turns out we're safely supporting Django 1.4 to 1.9 on Python 2.6 to 3.5 (Django 1.3 support dropped, because it's not finding the admin template under test; Python 2.4 and 2.5 support dropped, because they're not available to test against on Travis CI).

from django-app-namespace-template-loader.

@bittner what's your point then? To keep both projects alive?

from django-app-namespace-template-loader.

We should get the most out of both projects. Not throwing one away. Make a solid comparison.

We should:

• Make the code shorter, more readable, simpler -- maybe more pragmatic. (Profiling would be nice)
• Make the package future-proof, yet backward compatible as much as it makes sense. (Not everyone pins packages)
• Provide concise, self-contained documentation. (Less is more)

From an organizational point of view:

• Stick to semantic versioning. (Make consequences more obvious)
• Use a simple branching model. (GitHub Flow instead of gitflow)

Let me just say this bluntly: I'm not a fan of the "use version 0.x of this project (if you use Python 2.y)" approach. It's unprofessional for a general purpose package not to think of edge cases, and let your users do the research in commit messages, GitHub issues and single sentences of READMEs. Just because one and the same package stops working all of a sudden after an update. -- This is okay when you do a project as a single person. So, now we're joining forces. Let's rethink things. "There must be a better way..."

from django-app-namespace-template-loader.

Stick to semantic versioning. (Make consequences more obvious)

I agree, and that's why #15 bumps the version to 2.0 :)

Use a simple branching model. (GitHub Flow instead of gitflow)

@Fantomas42 already maintains a develop branch, is that okay?

Make the package future-proof, yet backward compatible as much as it makes sense.

That's addressed in #15: Changes do not affect users that have not pinned their versions as package name is retained and configuration steps remain the same.

I'm not a fan of the "use version 0.x of this project (if you use Python 2.y)"

Who said that? Or where is that said? Inevitably, projects will drop support of things and users will have to go back to their old versions... but I'm not suggesting to remove the django-apptemplates PyPi project's history of releases :)

I've already done a comparison with the time that I had, of the two READMEs. I added some badges and moved attribution of previous maintainers over from the old django-apptemplates. The django-app-namespace-template-loader README.rst may be longer, but it has more examples, too.. added some syntax highlighting for them btw.

As for code quality, I find that @Fantomas42's codebase will perform better by just reading the code. Example. I'm not going to be the one that benchmarks it, but I hope if you think that it's necessary, you will do it and find that my code analytics are okay :)

I appreciate that someone took the time to add tests for the "old" django-apptemplates, but I think that could've been saved by having made this decision before. Now, if we don't act, someone is also going to spend their time doing more tests, fixing tests, adding coverage support, adding Django 1.10 support etc... some of it on both these projects.. so my hypothesis is still that what's best for the community is to release the next django-app-namespace-template-loader as django-apptemplates==2.0.

I know it may seem easier to do nothing and thus avoid "doing a django-tagging", but I think it's well-worth the risk and effort, not just to avoid the future fragmentation of community and community resources, but also to showcase an example that the Django app ecology is not some unthoughtful, weedy NPM-like mess :)

If you still think it's a good idea, @bittner, it would be awesome if you reviewed #15 with whatever time you wanna invest in it.

from django-app-namespace-template-loader.

Hey, now that the "old" django-apptemplates is on Github and since the code-base of django-apptemplates is quite small, we could also try doing a full PR of @Fantomas42 's project directly onto it and review the changes in one giant changeset?

from django-app-namespace-template-loader.