PEP about recommended project folder layout

[c . buhtz]

Hello,

I am not sure if I looked into the correct sources. I was looking in 
"PEP 609 – Python Packaging Authority (PyPA) Governance" [1] and the 
"PyPA specifications" [2].


My question in short: Is there an official document (e.g. a PEP) about a 
recommended layout for project folders.


Looking into the wild and past there are a lot of variations of such 
layouts. I am far away from being a pro but depending on experience in 
my own projects and what I have learned from others (e.g. in 
blog-posts/tutorials) I recommend to have the "test" folder and the 
package folder side by side on the same level in the project folder (the 
root).


my_project
|- tests
|  └ test_*.py
|- my_package
|  └ __init__.py
└-- README.md

I sometimes add to it the so called "src"-Layout where the package 
folder is one level deeper in an extra "src" folder.


my_project
|- tests
|  └ test_*.py
|- src
|  └- my_package
| └ __init__.py
└-- README.md

I don't want to discuss the pros and cons of all variations. What I need 
is an official document I can use in discussions with other maintainers. 
If there is a PEP/document against my current recommendation I am also 
fine with this. ;)


Kind
Christian

[1] -- 
[2] -- 
--
https://mail.python.org/mailman/listinfo/python-list

venv and packages with entry points

[c . buhtz]

Hello,

I try to get it onto my head how virtual environments (via venv) works 
when I have packages with "entry points".


I can define such entry points in the setup.cfg like this (full example 
[1]):


[options.entry_points]
console_scripts =
hyperorg = hyperorg.__main__:main

When I install such a package via pip the result is a shell script in 
/usr/bin/...


What happens when I install such a package with an entry point via "pip 
install ." when an virtual environment is activated?


Kind
Christian

[1] -- 


--
https://mail.python.org/mailman/listinfo/python-list

Re: Which architectures to support in a CI like Travis?

[c . buhtz]

Dear Mats,

thanks for the reply.

Am 19.09.2022 16:10 schrieb Mats Wichmann:

Kind of unrelated to the actual question, but if you start doing
anything serious under Travis you'll run out of free minutes rather
quickly.  My project had to just give up on it after they changed
their licensing models


I'm new to Travis and didn't noticed that piece of information. ;)
Now I am more scared that Travis asked me for my credit card data no 
matter that I choose a "free" plan.


I'm a bit shocked and still don't understand the "credit" infos on my 
Travis account.
There are "Credits" ("used 4470 of 1 credits") and "OSS only 
credits" ("0 of your 0 monthly credits").


OSS == "open source software" ?

I'm confused and thought that Travis is free for public github repos. 
Any suggestions.


Kind
Christian
--
https://mail.python.org/mailman/listinfo/python-list

How to get the current set LOG_MASK in Python's syslog module?

[c . buhtz]

X-Post: https://stackoverflow.com/q/73814924/4865723

Hello,

I'm aware that there is a `logging` package that is more _modern_ then 
[`syslog`](https://docs.python.org/3/library/syslog.html). But I have 
old code here to deal with that does use `syslog`. So that question is 
specific to `syslog` and not to `logging`.


I would like to get the current `LOG_MASK`, which is kind of a logging 
level. According to the docu it seems that `syslog` doesn't have a 
mechanism for that.


Does someone has an idea?

The docu also tells me that `syslog` does let pass all messages by 
default.
My point is I do manipulate via `syslog.setlogmask()` the current log 
leve. At the end I would like to set it back to its previous value.


Kind
--
https://mail.python.org/mailman/listinfo/python-list

Re: pip/setuptools: Entry points not visible from pkexec-root-environment

[c . buhtz]

Dear Gerard,
thank you for your reply.

Am 18.12.2022 19:45 schrieb Weatherby,Gerard:

"sudo python3 -m pip
install -e ."

You’ve already started down a problematic road. I recommend installing
root level Python packages through your system package manager. (apt
for debian, or whatever RedHat is using now).


I'm totally with you at this point.

It is clear for me that distro maintainers sometimes using different 
mechanics.
But I'm the upstream maintainer and before handing offer a release to 
the distro that thing need to run without a distro. And that is pip. I 
also know a quit old project using "make" for that.


This question is independent from distros.


I’ve never used pkexec. Generally, just use sudo.


They are two very different things. There is a strict reason why I need 
to use pkexec here.


--
https://mail.python.org/mailman/listinfo/python-list

Re: pip/setuptools: Entry points not visible from pkexec-root-environment

[c . buhtz]

Dear Chris,

thank you for your reply.

Am 18.12.2022 20:27 schrieb Chris Angelico:

Does it have to be in path? Can't you say
/usr/local/bin/entrypointname? Not sure what constitutes an elegant
solution here.


I asked that myself. My current solution do determine the full path of 
the entrypoint via "which entrypoint".

I also think this is to my current knowledge the best solution.
--
https://mail.python.org/mailman/listinfo/python-list

Re: pip/setuptools: Entry points not visible from pkexec-root-environment

[c . buhtz]

Am 18.12.2022 22:37 schrieb Mats Wichmann:

the which command uses your PATH, so I'm not sure you're buying
anything new there


I'm using which before entering pkexec. ;)

I'll show a demonstrator project later.
--
https://mail.python.org/mailman/listinfo/python-list

Re: pip/setuptools: Entry points not visible from pkexec-root-environment

[c . buhtz]

Dear Barry,
thanks for reply and asking back.

Am 18.12.2022 22:33 schrieb Barry:

Why are asking on this list and discuss.python.org?


To be exact I'm asking in the "Packaging" section of 
"discuss.python.org". To my knowledge that section is the official 
channel of "pypa/pip" project pointed to from there own README.md [1].
To be complete. I also asked in in context of "pypa/setuptools" [2] and 
on the debian-python mailing list.


Not all questions are exactly the same but touching the same meta topic.
"pypa/setuptools" themselfs pointed me to the fact that they are not 
responsible for generating the entry-point-scripts but "pypa/pip" is. No 
matter both have "pypa/" in their names they seem technically different. 
This has reasons but is very confusing for "developers from the outside" 
like me. There are also alternative build-tools other then "setuptools". 
That is why I asked on that python-list here, too. The later was in the 
hope to maybe be pointed to alternative solutions away from setuptools 
and/or pip.


My apologize. When I decide for a solution I will point you to a 
demonstrator repository illustrating that solution.


[1] -- 
[2] -- 
--
https://mail.python.org/mailman/listinfo/python-list

Re: pip/setuptools: Entry points not visible from pkexec-root-environment

[c . buhtz]

Dear Chris,
thanks for asking back and my apologize for being to broad in my way of 
asking (in a foreign language).


Am 19.12.2022 07:40 schrieb Chris Angelico:

Hmm, then I'm not sure what you're *losing* here. The problem, as I
understand it, is that the scripts are getting installed into
/usr/local/bin (which is on PATH at the time they're installed), but
pkexec has a restricted PATH. So if you use which before pkexec'ing,
wouldn't you find the scripts, and then be able to run them without
regard to PATH?


Absolut correct. This works.

The question is if this is a "good" or "elegant" way from the viewpoint 
of different communities/projects (e.g. Python, setuptools, pip, other 
build-systems, distros, something I forgot).


I assume that I'm not the first person with such a use case. So there 
could be solutions out there. Maybe they are standardized solutions out 
there; e.g. a magic feature of setuptools or pip I haven't noticed yet.

--
https://mail.python.org/mailman/listinfo/python-list

Re: What should go to stdout/stderr and why Python logging write everything to stderr?

[c . buhtz]

Am 03.01.2023 17:51 schrieb r...@zedat.fu-berlin.de:

logging.getLogger().addHandler( logging.StreamHandler( sys.stdout ))


But I don't want to make all log levels go to stdout. Just DEBUG and 
INFO. But this would be a workaround.


The main question here is why does Python deciecded to make all logs go 
to stderr?
Maybe I totally misunderstood the intention of logging.info()?! Isn't 
this the "usual applicaton output"?


If not, what messages should go into logging.info()? Can you name me 
some examples?

--
https://mail.python.org/mailman/listinfo/python-list

Re: subprocess equivalent for "os.execvp()"?

[c . buhtz]

Dear Eryk,

Am 08.01.2023 17:22 schrieb Eryk Sun:

Avoid using any of the `os.exec*` functions on Windows. There's no
support for replacing a Windows process image, so the `exec*()`
functions simply spawn a child process and terminate the current one.


Thanks for bringing this up.

On Python for Windows what is the appropriate way how a process can call 
itself again?


Let me give you an example [1]:
There is a project "bitcli" having two entry points

[project.scripts]
bitcli = "bitcli.__main__:main"
bitcli-root = "bitcli.__main__:run_main_as_root_via_policykit"

The first is usual.

But the second does call "bitcli" via "pkexec" to give it some root 
rights.


This application is intended to be run as user or root by the user 
himself.


def run_main_as_root_via_policykit():
cmd = ['pkexec', '--disable-internal-agent', 'bitcli']

# See https://github.com/python/cpython/issues/39569
os.execvp(cmd[0], cmd)

Is there a better way to achiev this?

[1] -- 

--
https://mail.python.org/mailman/listinfo/python-list

[pygettext] --package-name and --package-version unknown

[c . buhtz]

Hello,

am I right to assume that "pygettext" is part of the official Python3 
"package"? So it is OK to aks here?


I do use pygettext to handle po and pot files. In the manpage I'm not 
able to find help about this.
I would like to modify the header that pygettext does create in each 
po-file.


How can I set the "Project-Id-Version"? With "xgettext" I would use the 
arguments "--package-name" and "--package-version" for this but they are 
unknown for "pygettext".


Kind
Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: [pygettext] --package-name and --package-version unknown

[c . buhtz]

Thanks for the answer.

Am 05.05.2023 03:24 schrieb aapost:

pygettext is deprecated since xgettext supports python now, so using
xgettext is recommended.


If this is the official case then it should be mentioned in the python 
docs. The 3.11 docs still tell about pygettext and xgettext and don't 
recommend one of it.

--
https://mail.python.org/mailman/listinfo/python-list