Re: Using setuptools to make django-admin.py runnable on Windows (#21340)

[Elena Williams]

Dear Florian,

Thanks so much for your update/feedback.

I updated the update 
here: https://github.com/elena/django-news-podcast/issues/1

Thanks again!
Elena


On Sunday, December 29, 2013 8:10:30 PM UTC+11, Florian Apolloner wrote:
>
> Just so we are all on the same page here (summarizing discussions from IRC 
> etc):
>
>  * We are not going to support setuptools and distutils, this makes the 
> setupprocess difficult to debug and test imo.
>  * Given Donald's "okay" we might switch to setuptools completely 
>  * There seems to be a bug in pip when installing a wheel, which renders 
> the django-admin.exe unusable on windows, help welcome
>  * PR for this issue is now at: 
> https://github.com/django/django/pull/2116[The original didn't work at all]
>
> Cheers,
> Florian
>
> On Sunday, November 24, 2013 7:18:15 PM UTC+1, Remram wrote:
>>
>> Hi developers, 
>>
>> On Windows, running the django-admin.py tool is painful[1], because 
>> .py scripts are not "executable". You might be able to run it using 
>> the full path (if Python is the default handler for .py files, which 
>> it really shouldn't be). Most probably you'll need to copy it to your 
>> project directory and prefix it with "python " each time. 
>>
>> setuptools has a neat workaround for scripts on Windows, which works 
>> great: it creates a wrapper binary that it puts on the PATH. I know 
>> from previous threads that Django chose to move away from setuptools 
>> and back to distutils, however it is easy to conditionally use this 
>> feature if setuptools are available. That way, Windows developers that 
>> have setuptools installed (which should be, like, all of them) will be 
>> able to run django-admin.py easily. 
>>
>> I submitted a pull request on Github[2] a month ago, then opened a 
>> ticket[3] later on. Apart from an uncommented update from akaariai, I 
>> didn't get any feedback. 
>>
>> I'd really like to see this small change accepted. It is fairly minor 
>> but would work towards restoring the portability that is a strength or 
>> Python. 
>>
>> Thanks for your input/reviews/time, 
>> -- Remram 
>>
>> [1] http://stackoverflow.com/q/19593404/711380 
>> [2] https://github.com/django/django/pull/1812 
>> [3] https://code.djangoproject.com/ticket/21340 
>>
>> TL;DR: what happened to my patch? 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3050acc2-266f-4d9b-a9b7-f9043dd46664%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Self-referenced template recursion handling

[unai]

Hi there!

> In fact, it allows arbitrary nesting and combinations. It works by
> keeping a list of possible sources for each template and as template
> is rendered it removes it from the list, so that next time it is not
> loaded anymore.

I'm not entirely convinced about maintaining a dicts of lists in the template
context containing the template candidates. I didn't work on this issue lately
but I managed to write a little article about it[0], kind of for my own
purposes.  In there I try to come with a way of knowing what would the next
template to be rendered be without storing continuously a list of templates. Of
course, the system I'm purposing could be totally wrong and don't have any
sense, so let me know what you think about it ;)

[0] 
http://unaizalakain.info/2013/12/19/self-referenced-template-inheritance-with-django/


signature.asc
Description: PGP signature

Re: Self-referenced template recursion handling

[Mitar]

Hi!

I just discovered this thread on the mailing list. I implemented also
template recursion in this modified django-overextends:

https://github.com/wlanslovenija/django-overextends/blob/nested-extends/overextends/templatetags/overextends_tags.py

It supports all possible combinations. For example, not just
"base.html" extending "base.html", but also "user.hml" extending
"base.html" which extends "base.html" (example:
https://github.com/mitar/overextends-test).

In fact, it allows arbitrary nesting and combinations. It works by
keeping a list of possible sources for each template and as template
is rendered it removes it from the list, so that next time it is not
loaded anymore.

Currently it is implemented as a custom tag and monkey-patches Django
to provide template origin to tokens also when TEMPLATE_DEBUG is
false.

See https://code.djangoproject.com/ticket/17199#comment:9

Comments band benchmarks are welcome.


Mitar

On Thu, Dec 12, 2013 at 12:33 AM, unai  wrote:
> Hi there!
>
>> I'm working on an other solution that instead of relying on loader
>> skipping relies on template skipping.
>
> Sorry for keeping you waiting on updates for so long!
>
> I was able to put some time into it today. Although it isn't nothing
> definitive and testing, benchmarking and docs are missing, here is some actual
> code for you to look at:
>
> https://github.com/unaizalakain/django/compare/template_selfreference
>
> You can totally ignore the testing commit. The loaders commit per se is
> relatively small and the idea behind it is quite simple. As you already know,
> any critic, suggestion or idea is highly appreciated ;-)
>
> I'm going to be able to put some more effort into this tomorrow.
>
> Best regards,
>
> Unai Zalakain



-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAKLmikMScJoj_Z%2BGM6PAPNQ_UVoG9xcT_C5dWOKQwtmbxwHMQg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Using setuptools to make django-admin.py runnable on Windows (#21340)

[Florian Apolloner]

Just so we are all on the same page here (summarizing discussions from IRC 
etc):

 * We are not going to support setuptools and distutils, this makes the 
setupprocess difficult to debug and test imo.
 * Given Donald's "okay" we might switch to setuptools completely 
 * There seems to be a bug in pip when installing a wheel, which renders 
the django-admin.exe unusable on windows, help welcome
 * PR for this issue is now at: https://github.com/django/django/pull/2116 
[The original didn't work at all]

Cheers,
Florian

On Sunday, November 24, 2013 7:18:15 PM UTC+1, Remram wrote:
>
> Hi developers, 
>
> On Windows, running the django-admin.py tool is painful[1], because 
> .py scripts are not "executable". You might be able to run it using 
> the full path (if Python is the default handler for .py files, which 
> it really shouldn't be). Most probably you'll need to copy it to your 
> project directory and prefix it with "python " each time. 
>
> setuptools has a neat workaround for scripts on Windows, which works 
> great: it creates a wrapper binary that it puts on the PATH. I know 
> from previous threads that Django chose to move away from setuptools 
> and back to distutils, however it is easy to conditionally use this 
> feature if setuptools are available. That way, Windows developers that 
> have setuptools installed (which should be, like, all of them) will be 
> able to run django-admin.py easily. 
>
> I submitted a pull request on Github[2] a month ago, then opened a 
> ticket[3] later on. Apart from an uncommented update from akaariai, I 
> didn't get any feedback. 
>
> I'd really like to see this small change accepted. It is fairly minor 
> but would work towards restoring the portability that is a strength or 
> Python. 
>
> Thanks for your input/reviews/time, 
> -- Remram 
>
> [1] http://stackoverflow.com/q/19593404/711380 
> [2] https://github.com/django/django/pull/1812 
> [3] https://code.djangoproject.com/ticket/21340 
>
> TL;DR: what happened to my patch? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/50fda77d-41c6-4e6b-92d6-585ce2ffd201%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.