Seems reasonable to me.
On Monday, January 11, 2016 at 10:24:18 AM UTC-5, Carl Johnson wrote:
>
> I think the template files should be shipped out as .py-tpl, since that's
> their type (a Python template), and the resulting final files should just
> have the extension renamed. Having two extensi
I think the template files should be shipped out as .py-tpl, since that's
their type (a Python template), and the resulting final files should just
have the extension renamed. Having two extension is just confusing and
leads to questions like this one about other kinds of templates.
--
You rec
Le mercredi 6 janvier 2016 19:34:07 UTC+1, Tim Graham a écrit :
>
> The current pull request proposes to make a backwards-incompatible change
> by chopping off any ".tpl" suffix in app or project template files. i.e.
> "If you are using custom templates and these templates already use a
> ``.tpl
The current pull request proposes to make a backwards-incompatible change
by chopping off any ".tpl" suffix in app or project template files. i.e.
"If you are using custom templates and these templates already use a
``.tpl`` suffix, you will need to append an additional ``.tpl`` (ie.
``filenam
FWIW, this also bit me. I have a deploy script that runs python -m
compileall as part of its build process. It was pretty easy to work around
by adding -x app_template, but why make everyone else work around Django?
ISTM it would be better to call the files .py_template instead since they
aren'
Hello,
I'm another Debian developer co-maintaining Django in Debian.
Le lundi 30 novembre 2015, Florian Apolloner a écrit :
> I am not against including it, but depending on how packaging works in
> Debian it could be possible to call pycompile with a proper exclusion list
> instead. The PR its
On Monday, November 30, 2015 at 7:02:05 PM UTC+1, Tim Graham wrote:
>
> Florian, your preference is to decline the change proposed by Chris and
> just deal with any support queries when people see a log like below? I
> understand it's not ideal to add workarounds for bugs in other software as
Actually, the SyntaxError issue isn't related to pip but to setuptools 5.5
and 5.5.1 (Debian stable ships the latter).
Florian, your preference is to decline the change proposed by Chris and
just deal with any support queries when people see a log like below? I
understand it's not ideal to add
Damn, I meant to write "and not real packages"
On Sunday, November 29, 2015 at 2:46:22 AM UTC+1, Florian Apolloner wrote:
>
>
>
> On Saturday, November 28, 2015 at 7:16:10 PM UTC+1, lamby wrote:
>>
>> > at least project_template would be missing etc
>>
>> Deliberately so; these are not invalid .py
On Saturday, November 28, 2015 at 7:16:10 PM UTC+1, lamby wrote:
>
> > at least project_template would be missing etc
>
> Deliberately so; these are not invalid .py files.
>
Yes, but by luck and/or accident. In the end they are still package data
and real packages, so you should never run pycom
> I believe this is a new issue in 1.9, not 1.8 as the subject says,
correct?
Correct, apologies. (I meant to write "since 1.8" as "1.9" is either
ambiguous or not released yet.)
> Is the "man-page of pycompile you can exclude certain packages"
suggestion some change we should make in Django?
"Force" or "nudge" to upgrade pip? i.e. should Django not install with pip
< some version? That seems controversial.
Is the "man-page of pycompile you can exclude certain packages" suggestion
some change we should make in Django? As long as we have some solution to
avoid support queries about t
If I am not mistaken 1.5.6 is still one of those versions which whould
install from external sources etc… So from a security point of view I wanna
force people to upgrade.
Regarding purity: No it is not purity, as the PR already showed, at least
project_template would be missing etc… Also this
Yes, I know but it creates confusion for users and has resulted in at least
two bug reports like https://code.djangoproject.com/ticket/25584. I suspect
we'll see more reports and queries about it once 1.9 goes final so I'd like
to avoid that as long as there isn't any downside to the proposed ch
> On Nov 28, 2015, at 11:03 AM, Tim Graham wrote:
>
> Claude said, "I also encountered this error when using pip 1.5.6 (default
> version in Debian stable)." I guess at least some people might not want to
> upgrade system packages.
>
> Is your main opposition to the change a "purity" one? Sur
Claude said, "I also encountered this error when using pip 1.5.6 (default
version in Debian stable)." I guess at least some people might not want to
upgrade system packages.
Is your main opposition to the change a "purity" one? Sure, we could add a
pip version check, but I don't see any downsid
I rather add a check to setup.py and tell people to upgrade pip
On Saturday, November 28, 2015 at 1:46:48 PM UTC+1, Tim Graham wrote:
>
> I believe this is a new issue in 1.9, not 1.8 as the subject says, correct?
>
> I wouldn't mind seeing it fixed as old versions of pip report a
> SyntaxError w
I believe this is a new issue in 1.9, not 1.8 as the subject says, correct?
I wouldn't mind seeing it fixed as old versions of pip report a SyntaxError
when installing Django (this doesn't affect the install, but creates
confusion for users and resulted in at least two bug reports like
https://
Hi,
Those packages/modules are clearly marked as package data
(https://github.com/django/django/blob/master/setup.py#L26-L28), so imo it
is a bug in Debian packaging (although I do understand that it might not be
the easiest to fix…). According to the man-page of pycompile you can
exclude cert
Hi,
I sent this first as a pull request — talk is cheap, code is better,
etc. — but now feel I should I have posted here first.
The underlying issue is that Debian packages unconditionally
byte-compile .py files under dist-packages upon installation using
`pycompile` and do not silence errors by
20 matches
Mail list logo
