bug#27447: pelican-quickstart produces files with store path shebangs

bug#27447: pelican-quickstart produces files with store path shebangs

[ng0]

In a pelican directory after running pelican-quickstart:

egrep -nr "store"
…
pelicanconf.py:1:#!/gnu/store/bf54hnwd8mb63zmssc23fwslf5zvxpxs-python-wrapper-3.5.3/bin/python
develop_server.sh:1:#!/gnu/store/k7029k5va68lkapbzcycdzj7m5bjb4b8-bash-4.4.12/bin/bash
publishconf.py:1:#!/gnu/store/bf54hnwd8mb63zmssc23fwslf5zvxpxs-python-wrapper-3.5.3/bin/python


We have a couple more bugs like this. If they are already grouped,
add this bug to them.
-- 
ng0
OpenPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
https://krosos.org/~/ng0/ https://www.infotropique.org

bug#27447: pelican-quickstart produces files with store path shebangs

[zimoun]

Hi

On Thu, 22 Jun 2017 at 12:35, ng0 <ng0@infotropique.org> wrote:
> In a pelican directory after running pelican-quickstart:
>
> egrep -nr "store"
> …
> pelicanconf.py:1:#!/gnu/store/bf54hnwd8mb63zmssc23fwslf5zvxpxs-python-wrapper-3.5.3/bin/python
> develop_server.sh:1:#!/gnu/store/k7029k5va68lkapbzcycdzj7m5bjb4b8-bash-4.4.12/bin/bash
> publishconf.py:1:#!/gnu/store/bf54hnwd8mb63zmssc23fwslf5zvxpxs-python-wrapper-3.5.3/bin/python
>
> We have a couple more bugs like this. If they are already grouped,
> add this bug to them.

What are these oyther “couple more bugs like this”?

<http://issues.guix.gnu.org/issue/27447>

All the best,
simon

bug#27447: pelican-quickstart produces files with store path shebangs

[zimoun]

Hi,

On Fri, 18 Dec 2020 at 21:10, zimoun <zimon.toutoune@gmail.com> wrote:
> On Thu, 22 Jun 2017 at 12:35, ng0 <ng0@infotropique.org> wrote:

>> In a pelican directory after running pelican-quickstart:
>>
>> egrep -nr "store"
>> …
>> pelicanconf.py:1:#!/gnu/store/bf54hnwd8mb63zmssc23fwslf5zvxpxs-python-wrapper-3.5.3/bin/python
>> develop_server.sh:1:#!/gnu/store/k7029k5va68lkapbzcycdzj7m5bjb4b8-bash-4.4.12/bin/bash
>> publishconf.py:1:#!/gnu/store/bf54hnwd8mb63zmssc23fwslf5zvxpxs-python-wrapper-3.5.3/bin/python
>>
>> We have a couple more bugs like this. If they are already grouped,
>> add this bug to them.
>
> What are these other “couple more bugs like this”?
>
> <http://issues.guix.gnu.org/issue/27447>

No moreinfo so I am closing.  If I am missing something, then please
reopen it.


All the best,
simon

bug#27447: pelican-quickstart produces files with store path shebangs

[Mark H Weaver]

reopen 27447
thanks

Hi Simon,

zimoun <zimon.toutoune@gmail.com> writes:

> On Fri, 18 Dec 2020 at 21:10, zimoun <zimon.toutoune@gmail.com> wrote:
>> On Thu, 22 Jun 2017 at 12:35, ng0 <ng0@infotropique.org> wrote:
>
>>> In a pelican directory after running pelican-quickstart:
>>>
>>> egrep -nr "store"
>>> …
>>> pelicanconf.py:1:#!/gnu/store/bf54hnwd8mb63zmssc23fwslf5zvxpxs-python-wrapper-3.5.3/bin/python
>>> develop_server.sh:1:#!/gnu/store/k7029k5va68lkapbzcycdzj7m5bjb4b8-bash-4.4.12/bin/bash
>>> publishconf.py:1:#!/gnu/store/bf54hnwd8mb63zmssc23fwslf5zvxpxs-python-wrapper-3.5.3/bin/python
>>>
>>> We have a couple more bugs like this. If they are already grouped,
>>> add this bug to them.
>>
>> What are these other “couple more bugs like this”?
>>
>> <http://issues.guix.gnu.org/issue/27447>
>
> No moreinfo so I am closing.  If I am missing something, then please
> reopen it.

The lack of response about the "couple more bugs like this" does not
invalidate the bug reported in this bug report.  I think it was merely a
suggestion that this bug might possibly be merged with other similar
bugs.  The key point is that we don't need an answer to that question to
investigate/fix this bug.

Unless we have reason to believe that 'pelican-quickstart' is no longer
embedding store paths in the generated files, I think we should keep
this bug open.  Does that make sense?

    Regards,
      Mark

bug#27447: pelican-quickstart produces files with store path shebangs

[zimoun]

Hi Mark,

First, one key point is the dates…

>> On Fri, 18 Dec 2020 at 21:10, zimoun <zimon.toutoune@gmail.com> wrote:
>>> On Thu, 22 Jun 2017 at 12:35, ng0 <ng0@infotropique.org> wrote:

…so more than 3 years without any comment.  By without any comment, I
mean literally no comment; my email was the first.  I can tell you that
most of the old and forgotten bug reports like this one are simply
emails addressed to incorrect list (bug-guix instead of guix-devel); as
a rule of thumb.  I am trying hard to avoid some false positive by first
understand and second carefully check, so if I do not understand nor be
able to check then I let the report as it is. Well, I am sorry if I have
failed to one or the other.

Second, it does not appear to me a bug.  The “quickstart” generates
local configuration files that contain absolute path to the Python
interpreter.

--8<---------------cut here---------------start------------->8---
$ guix environment -C --ad-hoc pelican coreutils grep
[env]$ mkdir foo && cd foo && ls -l
total 0

[env]$ pelican-quickstart
Welcome to pelican-quickstart v4.2.0.

This script will help you create a new Pelican-based website.

Please answer the following questions so this script can generate the files
needed by Pelican.

    
> Where do you want to create your new web site? [.] 
> What will be the title of this web site? Foo
> Who will be the author of this web site? zimoun
> What will be the default language of this web site? [en] 
> Do you want to specify a URL prefix? e.g., https://example.com   (Y/n) n
> Do you want to enable article pagination? (Y/n) n
> What is your time zone? [Europe/Paris] 
> Do you want to generate a tasks.py/Makefile to automate generation and publishing? (Y/n) y
> Do you want to upload your website using FTP? (y/N) N
> Do you want to upload your website using SSH? (y/N) N
> Do you want to upload your website using Dropbox? (y/N) N
> Do you want to upload your website using S3? (y/N) N
> Do you want to upload your website using Rackspace Cloud Files? (y/N) N
> Do you want to upload your website using GitHub Pages? (y/N) N
Done. Your new project is available at /tmp/bar

[env]$ ls
Makefile  content  output  pelicanconf.py  publishconf.py  tasks.py

[env]$ egrep -nr "store"
pelicanconf.py:1:#!/gnu/store/h8jw9qhyfp6fm6nb3cgh4335qhr31wfz-python-wrapper-3.8.2/bin/python
publishconf.py:1:#!/gnu/store/h8jw9qhyfp6fm6nb3cgh4335qhr31wfz-python-wrapper-3.8.2/bin/python
--8<---------------cut here---------------end--------------->8---

Why is it a bug?

Since the test suite is #f, I have not checked if the package is really
functional.  But the last updates are in 2019-12-29 and a revamp in
2019-01-15 so I assumed the package is functional and this reference in
config files is not an issue.

>>>> We have a couple more bugs like this. If they are already grouped,
>>>> add this bug to them.
>>>
>>> What are these other “couple more bugs like this”?
>>>
>>> <http://issues.guix.gnu.org/issue/27447>
>>
>> No moreinfo so I am closing.  If I am missing something, then please
>> reopen it.

Third, no moreinfo about the bug itself, which I consider myself as
notabug.  And no moreinfo about other cases to examine them case per
case.  So I closed after waiting couple of weeks.

BTW, the submitter of the report clearly stated they is not working on
Guix anymore [1], therefore, they will no provide moreinfo.

1: <http://logs.guix.gnu.org/guix/2020-12-01.log#230743>


> The lack of response about the "couple more bugs like this" does not
> invalidate the bug reported in this bug report.  I think it was merely a
> suggestion that this bug might possibly be merged with other similar
> bugs.  The key point is that we don't need an answer to that question to
> investigate/fix this bug.

Sorry if it has not appeared as this but I have investigated this bug
and from my understanding, it is not a bug.  Since no one commented, I
have moved forward.  Again sorry if I have missed something.


> Unless we have reason to believe that 'pelican-quickstart' is no longer
> embedding store paths in the generated files, I think we should keep
> this bug open.  Does that make sense?

Why does embed store paths in configuration files is an issue?  Pelican
is a Python application which therefore requires a Python interpreter.
Running ’pelican’ against another Python VM than the one it was built
seems a bad idea.

And if the point is run “pelican-quickstart” with one Pelican version
built against one Python VM, and then reuse these generated config files
with another Pelican version built against another Python VM, in this
use-case, the bug is upstream because it embeds absolute path which does
not respect PEP 394 [2].  I agree that in this case, the bug should/must
still be opened until upstream fix.

Well, I am probably missing the story about shebang and Guix.

2: <https://www.python.org/dev/peps/pep-0394/>


All the best,
simon

bug#27447: pelican-quickstart produces files with store path shebangs

[Mark H Weaver]

Hi Simon,

zimoun <zimon.toutoune@gmail.com> writes:

> First, one key point is the dates…
>
>>> On Fri, 18 Dec 2020 at 21:10, zimoun <zimon.toutoune@gmail.com> wrote:
>>>> On Thu, 22 Jun 2017 at 12:35, ng0 <ng0@infotropique.org> wrote:
>
> …so more than 3 years without any comment.

That a bug has been neglected for years does not imply that it's no
longer a bug, or that we should forget about it.

> Second, it does not appear to me a bug.  The “quickstart” generates
> local configuration files that contain absolute path to the Python
> interpreter.
>
> --8<---------------cut here---------------start------------->8---
> $ guix environment -C --ad-hoc pelican coreutils grep
> [env]$ mkdir foo && cd foo && ls -l
> total 0
>
> [env]$ pelican-quickstart
> Welcome to pelican-quickstart v4.2.0.
>
> This script will help you create a new Pelican-based website.
>
> Please answer the following questions so this script can generate the files
> needed by Pelican.
>
>     
>> Where do you want to create your new web site? [.] 
>> What will be the title of this web site? Foo
>> Who will be the author of this web site? zimoun
>> What will be the default language of this web site? [en] 
>> Do you want to specify a URL prefix? e.g., https://example.com   (Y/n) n
>> Do you want to enable article pagination? (Y/n) n
>> What is your time zone? [Europe/Paris] 
>> Do you want to generate a tasks.py/Makefile to automate generation and publishing? (Y/n) y
>> Do you want to upload your website using FTP? (y/N) N
>> Do you want to upload your website using SSH? (y/N) N
>> Do you want to upload your website using Dropbox? (y/N) N
>> Do you want to upload your website using S3? (y/N) N
>> Do you want to upload your website using Rackspace Cloud Files? (y/N) N
>> Do you want to upload your website using GitHub Pages? (y/N) N
> Done. Your new project is available at /tmp/bar
>
> [env]$ ls
> Makefile  content  output  pelicanconf.py  publishconf.py  tasks.py
>
> [env]$ egrep -nr "store"
> pelicanconf.py:1:#!/gnu/store/h8jw9qhyfp6fm6nb3cgh4335qhr31wfz-python-wrapper-3.8.2/bin/python
> publishconf.py:1:#!/gnu/store/h8jw9qhyfp6fm6nb3cgh4335qhr31wfz-python-wrapper-3.8.2/bin/python
> --8<---------------cut here---------------end--------------->8---
>
> Why is it a bug?

It's a bug because these absolute file names will cease to exist after
the next 'core-updates' merge happens, and more precisely after the
older system generations (or user profiles) are deleted and 'guix gc'
subsequently deletes these obsolete store items.

At that point, maybe things will break.  I think that would need to be
investigated before dismissing this bug report.

>>> No moreinfo so I am closing.  If I am missing something, then please
>>> reopen it.
>
> Third, no moreinfo about the bug itself, which I consider myself as
> notabug.

In many cases, the lack of "moreinfo" prevents us from further
investigating a bug, and in such cases I agree that it is justifiable to
close a bug report.  For example, users often report a bug that we are
unable to reproduce, and then they stop communicating.

However, this case is quite different.  In this case, we already enough
information to reproduce and investigate this bug.  The "moreinfo" that
you requested was regarding a side comment that ng0 made about the
possibility of other similar bugs that might be merged with this one.
The fact that ng0 never answered that side question doesn't imply that
the bug he reported is no longer relevant.

I think that there's good reason to believe that this bug is still
relevant.  It certainly has not yet been established here that this bug
does not exist or is harmless.  Therefore, we should not forget about
it, even if ng0 has moved on.

Does that make sense?

Nonetheless, I very much appreciate your ongoing work on these old bug
reports.  It is a great help.

     Regards,
       Mark

bug#27447: pelican-quickstart produces files with store path shebangs

[zimoun]

Hi Mark,

On Thu, 14 Jan 2021 at 18:00, Mark H Weaver <mhw@netris.org> wrote:
> zimoun <zimon.toutoune@gmail.com> writes:

>> --8<---------------cut here---------------start------------->8---
>> $ guix environment -C --ad-hoc pelican coreutils grep
>> [env]$ mkdir foo && cd foo && ls -l
>> total 0
>>
>> [env]$ pelican-quickstart
>> Welcome to pelican-quickstart v4.2.0.
>>
>> This script will help you create a new Pelican-based website.
>>
>> Please answer the following questions so this script can generate the files
>> needed by Pelican.
>>
>>
>>> Where do you want to create your new web site? [.]
>>> What will be the title of this web site? Foo
>>> Who will be the author of this web site? zimoun
>>> What will be the default language of this web site? [en]
>>> Do you want to specify a URL prefix? e.g., https://example.com   (Y/n) n
>>> Do you want to enable article pagination? (Y/n) n
>>> What is your time zone? [Europe/Paris]
>>> Do you want to generate a tasks.py/Makefile to automate generation and publishing? (Y/n) y
>>> Do you want to upload your website using FTP? (y/N) N
>>> Do you want to upload your website using SSH? (y/N) N
>>> Do you want to upload your website using Dropbox? (y/N) N
>>> Do you want to upload your website using S3? (y/N) N
>>> Do you want to upload your website using Rackspace Cloud Files? (y/N) N
>>> Do you want to upload your website using GitHub Pages? (y/N) N
>> Done. Your new project is available at /tmp/bar
>>
>> [env]$ ls
>> Makefile  content  output  pelicanconf.py  publishconf.py  tasks.py
>>
>> [env]$ egrep -nr "store"
>> pelicanconf.py:1:#!/gnu/store/h8jw9qhyfp6fm6nb3cgh4335qhr31wfz-python-wrapper-3.8.2/bin/python
>> publishconf.py:1:#!/gnu/store/h8jw9qhyfp6fm6nb3cgh4335qhr31wfz-python-wrapper-3.8.2/bin/python
>> --8<---------------cut here---------------end--------------->8---
>>
>> Why is it a bug?
>
> It's a bug because these absolute file names will cease to exist after
> the next 'core-updates' merge happens, and more precisely after the
> older system generations (or user profiles) are deleted and 'guix gc'
> subsequently deletes these obsolete store items.
>
> At that point, maybe things will break.  I think that would need to be
> investigated before dismissing this bug report.

I still miss why it is a bug.  The script ’pelican-quickstart’ is an
*helper* to generate this configuration file ’pelicancon.py’.
Therefore, the user should review it, IMHO.

Let consider this scenario:

    1. guix install pelican
    2. pelican-quickstart
    3. guix pull
    4. guix upgrade
    5. guix gc

At step #2, the generated configuration file is in agreement with the
Python interpreter.  Then, I agree that this Python could be gone after
the GC.

However, there is no guarantee that the generated configuration file at
step #2 still works with the potentially upgraded Pelican version (step
#4); independently of the shebang issue we are speaking.

Somehow, it is the responsibility of the user to maintain their
configuration file across the Pelican versions.

Well, considering my previous words [1],

        Why does embed store paths in configuration files is an issue?
        Pelican is a Python application which therefore requires a
        Python interpreter.  Running ’pelican’ against another Python VM
        than the one it was built seems a bad idea.

        And if the point is run “pelican-quickstart” with one Pelican
        version built against one Python VM, and then reuse these
        generated config files with another Pelican version built
        against another Python VM, in this use-case, the bug is upstream
        because it embeds absolute path which does not respect PEP 394
        [2].

I still think the bug is upstream.  Anyway.  The point is to resolve
and close this report. ;-)

First, I am not sure Pelican is a lot run by Guix users.  The version
4.2.0 seems from Oct. 2019 and the last upstream version is 4.6 from
March 2021.  Running,

  $ ./pre-inst-env guix refresh -u pelican
  $ ./pre-inst-env guix environment -C --ad-hoc pelican \
                        -- pelican-quickstart

does not fix the issue. (Maybe I will submit the resulting update,
separately.)


Second, do we patch Pelican to remove?  If yes, these absolute file
names in the generated configuration file should be replaced by what?


Cheers,
simon

1: <http://issues.guix.gnu.org/issue/27447#6>
2: <https://www.python.org/dev/peps/pep-0394/>

bug#27447: pelican-quickstart produces files with store path shebangs

[Ben Sturmfels via Bug reports for GNU Guix]

> ng0 wrote on 22 Jun 2017 14:35:
>
> In a pelican directory after running pelican-quickstart:
> egrep -nr "store"
> …
> pelicanconf.py:1:#!/gnu/store/bf54hnwd8mb63zmssc23fwslf5zvxpxs-python-wrapper-3.5.3/bin/python
> develop_server.sh:1:#!/gnu/store/k7029k5va68lkapbzcycdzj7m5bjb4b8-bash-4.4.12/bin/bash
> publishconf.py:1:#!/gnu/store/bf54hnwd8mb63zmssc23fwslf5zvxpxs-python-wrapper-3.5.3/bin/python

This is a technically a bug, but it's in upstream and has no effect in
practise, so I'll close this bug report. Details below.

As of Pelican 4.7.0 which I've just submitted an update patch for,
develop_server.sh is no longer created:

$ egrep -nr "store"
pelicanconf.py:1:#!/gnu/store/nckjv3ccwdi6096j478gvns43ssbls2p-python-wrapper-3.8.2/bin/python
publishconf.py:1:#!/gnu/store/nckjv3ccwdi6096j478gvns43ssbls2p-python-wrapper-3.8.2/bin/python

This is *technically* a bug because these configuration files are
created once when the user is setting up their blog and will be used
forever after. In practise though, there's no issue since these files
are not executable - they are configuration only.

This also isn't a packaging bug in Guix, it's upstream as zimoun
suggests. Here's the first line of those files as generated by upstream
pelican-quickstart:

$ head -n1 pelicanconf.py publishconf.py 
==> pelicanconf.py <==
#!/usr/bin/env python

==> publishconf.py <==
#!/usr/bin/env python

These upstream files should not contain shebangs since they are not
executable or ever intended to be executed directly - they're config
only and have no functionality.

Regards,
Ben

bug#27447: pelican-quickstart produces files with store path shebangs

[Ben Sturmfels via Bug reports for GNU Guix]

On Tue, 05 Oct 2021, Ben Sturmfels wrote:

>> ng0 wrote on 22 Jun 2017 14:35:
>>
>> In a pelican directory after running pelican-quickstart:
>> egrep -nr "store"
>> …
>> pelicanconf.py:1:#!/gnu/store/bf54hnwd8mb63zmssc23fwslf5zvxpxs-python-wrapper-3.5.3/bin/python
>> develop_server.sh:1:#!/gnu/store/k7029k5va68lkapbzcycdzj7m5bjb4b8-bash-4.4.12/bin/bash
>> publishconf.py:1:#!/gnu/store/bf54hnwd8mb63zmssc23fwslf5zvxpxs-python-wrapper-3.5.3/bin/python
>
> This is a technically a bug, but it's in upstream and has no effect in
> practise, so I'll close this bug report. Details below.
>
> As of Pelican 4.7.0 which I've just submitted an update patch for,
> develop_server.sh is no longer created:
>
> $ egrep -nr "store"
> pelicanconf.py:1:#!/gnu/store/nckjv3ccwdi6096j478gvns43ssbls2p-python-wrapper-3.8.2/bin/python
> publishconf.py:1:#!/gnu/store/nckjv3ccwdi6096j478gvns43ssbls2p-python-wrapper-3.8.2/bin/python
>
> This is *technically* a bug because these configuration files are
> created once when the user is setting up their blog and will be used
> forever after. In practise though, there's no issue since these files
> are not executable - they are configuration only.
>
> This also isn't a packaging bug in Guix, it's upstream as zimoun
> suggests. Here's the first line of those files as generated by upstream
> pelican-quickstart:
>
> $ head -n1 pelicanconf.py publishconf.py 
> ==> pelicanconf.py <==
> #!/usr/bin/env python
>
> ==> publishconf.py <==
> #!/usr/bin/env python
>
> These upstream files should not contain shebangs since they are not
> executable or ever intended to be executed directly - they're config
> only and have no functionality.

I've now submitted a patch upstream:

https://github.com/getpelican/pelican/pull/2932

Closing.