[Distutils] Re: Fwd: Re: Use of "python" shebang an installation error?

[John Thorvald Wodder II]

On 2020 Jul 22, at 14:30, David Mathog  wrote:
> Scripts usually end up in a "bin" directory on linux.  Is that part of
> the installation standard or could a package put them in an arbitrary
> path (other than under "site-packages") under the venv's root, for
> instance in a directory named "scripts"?

Pip always puts commands — both those declared with console_scripts entry 
points and those declared as "scripts" — in a bin/ directory (or whatever the 
equivalent is on Windows).  The individual packages get no say in this.

-- John Wodder
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/GO5YXRXVSZGC5BG2JURVD2NBIUZU54AD/

[Distutils] Re: Use of "python" shebang an installation error?

[John Thorvald Wodder II]

On 2020 Jul 20, at 15:25, David Mathog  wrote:
> Lately I have been working on a CentOS 8 machine, and it has "python2"
> and "python3", but no "python".  Many packages install scripts with a
> shebang like:
> 
>   #!/usr/bin/env python
> 
> and those do not work on this OS.  Seems like rather a large missing
> dependency which goes by without triggering a fatal error.

How exactly are these packages getting installed?  Last time I checked, both 
pip and setuptools automatically set the shebang in scripts (both 
console_script entry points and scripts declared with the "scripts" argument to 
`setup()`) to use the path of the running Python interpreter.  Are these 
packages installed using your system package manager?  If so, you should take 
the problem up with its maintainers.

-- John Wodder
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/CW7VQQERRDOYGDFRL4RSIU3HSHFLHSPN/

[Distutils] Re: package management - common storage while keeping the versions straight

[John Thorvald Wodder II]

On 2020 Jun 29, at 16:09, David Mathog  wrote:
> 
> In neither case does the egg-info file reference the corresponding
> directory, but at least the directory in both has the expected package
> name (other than case).  In the examples you cited at the top, were
> any of those "different name" cases from packages with a "file"
> egg-info?

The projects I examined were all in wheel form and thus had *.dist-info 
directories instead of *.egg-info.  I know very little about how eggs work, 
other than that they're deprecated and should be avoided in favor of wheels.

-- John Wodder
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/DMRPHSWPXPEWJOHFZVBKTJMH34KABHTM/

[Distutils] Re: package management - common storage while keeping the versions straight

[John Thorvald Wodder II]

On 2020 Jun 26, at 15:50, David Mathog  wrote:

> Still, how common is that?  Can anybody offer an estimate about what
> fraction of packages use different names like that?

Scanning through the wheelodex.org database (specifically, a dump from earlier 
this week) finds 32,517 projects where the wheel DOES NOT contain a top-level 
module of the same name as the project (after correcting for differences in 
case and hyphen vs. underscore vs. period) and 74,073 projects where the wheel 
DOES contain a module of the same name.  (5,417 projects containing no modules 
were excluded.)  Note that a project named "foo-bar" containing a namespace 
package "foo/bar" is counted in the former group.

Of the 32,517 non-matching projects, 7,117 were Odoo projects with project 
names of the form "odoo{version}_addon_{foo}" containing namespace modules of 
the form "odoo/addons/{foo}", and 3,175 were Django projects with project names 
of the form "django_{foo}" containing packages named just "{foo}".  No other 
major patterns seem to stand out.

-- John Wodder
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/V445KCPLKMEVSSEAKX776DMNSPL76JRR/

[Distutils] Re: package management - common storage while keeping the versions straight

[John Thorvald Wodder II]

(Sending to the list this time.)

On 2020 Jun 26, at 15:43, David Mathog  wrote:
> So by what method could code working outside of python possibly determine that
> "yaml" goes with "PyYAML"?

By checking all *.dist-info/RECORD files to see which one mentions the "yaml" 
directory.  (top_level.txt could also be checked, but I believe that only 
setuptools creates this file — projects built with flit or poetry don't have it 
— and it's not very helpful when namespace packages are involved.)

>  Is this a common situation?

It happens whenever the project "foo" distributes a module named something 
other than "foo".  Other projects like this that I can think of off the top of 
my head are BeautifulSoup4 (module: bs4), python-dateutil (module: dateutil), 
and attrs (module: attr).

> Is pkg_resources actually a package?

pkg_resources is a module distributed by the setuptools project (alongside the 
modules "setuptools" and "easy_install").

> Does it make sense for a common
> package repository to have a single instance of this directory or
> should each installed python based program retain its own version of
> this?

There should be one instance per each version of setuptools stored in the 
repository.

-- John Wodder
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/IP7LRY5ZGDBIGSW4Q4SMJ7WM6WM6ZSVW/

[Distutils] Re: [setuptools] Install entry point only if extras_require are satisfied?

[John Thorvald Wodder II]

On 2020 Feb 29, at 02:00, Jonatan Palsson  wrote:
> I would like to change the behavior, so that the entry point is *not
> installed* if the extra dependencies are not available (and perhaps
> also show a warning, indicating that this entry point has not been
> installed).

I don't believe this is possible.  Achieving this new behavior would, at a 
minimum, require changes to pip (and possibly also to the entry points format 
in order to indicate which behavior is desired).  As associating extras with 
entry points is currently considered deprecated to begin with, I doubt you'd 
have much luck convincing the pip maintainers to add such a feature.

The closest way to get the behavior you want would be to split off the 
CLI-specific code from your project into a separate project, and have this new 
project install the entry point while always depending on the first project and 
the "CLI" extras.

-- John Wodder
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/ZVEIOTED6VBSMWRBXQWJHMWH6O6NCLXJ/

[Distutils] Re: Troubles with pip

[John Thorvald Wodder II]

By default, the only site that pip fetches data from is , 
which is currently up.  Are you perhaps behind a firewall that blocks access to 
PyPI?  Can you access pypi.org from the command line of your system (e.g., with 
curl or wget)?

-- John Wodder

> On 2020 Feb 9, at 15:34, George R Goffe via Distutils-SIG 
>  wrote:
> 
> Hi,
> 
> I'm very new to this python community.
> 
> This system is a FedoraCore 32 x86_64 (Rawhide) freshly installed.
> 
> I was reading about beautifulsoup... and was directed to use pip "pip install 
> beautifulsoup4". I got nothing. strace -xvfp  shows that pip is 
> in (hung?) in the recvfrom(...) system call.
> 
> Is pip trying to "talk" with a site that's down? Perhaps I'm not doing 
> something correctly?
> 
> Thanks for your help,
> 
> George...
> --
> Distutils-SIG mailing list -- distutils-sig@python.org
> To unsubscribe send an email to distutils-sig-le...@python.org
> https://mail.python.org/mailman3/lists/distutils-sig.python.org/
> Message archived at 
> https://mail.python.org/archives/list/distutils-sig@python.org/message/S6SBB5SOOPRLUVQRGNG4RUHHM5XLTVTI/
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/UV6OIAWLTI72V7M2N765ZGNVGKRUBHEB/

[Distutils] Announcing Wheelodex

[John Thorvald Wodder II]

I've created a website that is likely to be of interest to people here: 
Wheelodex , a site for browsing the metadata of 
wheels on PyPI.

It allows you to find out what projects a wheel depends on, what other projects 
depend on a given project, what commands & other entry points a wheel defines, 
what files are in a wheel, etc.  You can even search for wheels containing a 
given module or file, or browse a list of all commands & other entry points 
defined by wheels.  There's also a basic API for getting wheel data as JSON: 
.

I'm open to suggestions on what else to do with the data.  I'm also open to 
suggestions on how to make the interface look less sucky.

-- John Wodder
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/IHJU6RAUBFIEEDVR46BDT76F7XOHQ7OM/

[Distutils]Re: pypi/twine complains about license

[John Thorvald Wodder II]

On 2018 Jul 12, at 07:20, Robin Becker  wrote:
> 
> 
>> (full list: https://opensource.org/licenses/alphabetical)
>> The Reportlab licence is listed as "BSD License (BSD license (see 
>> license.txt for details)", but, AFAICS, none of the downloadable files 
>> actually include a license.txt file.
>> (This means redistributing these files is against either of the BSD licences 
>> – they both say "Redistributions of source code must retain the above 
>> copyright notice, this list of conditions and the following disclaimer.")
>> -- 
> ...
> I added the license.txt file that is in source to the setup.py package_data 
> list. However, for the pyRXP package we don't have a way to add the license 
> as this is a pure binary extension which sits on the PYTHONPATH. Is there a 
> setup mechanism to add arbitrary files without a package? As a stopgap I put 
> the source of the license into the setup(license) keyword so the text of the 
> license appears in pyRXP.egg-info inside  PKG-INFO

I believe the current standard way to distribute a LICENSE file with a package 
is to add "include LICENSE" (or whatever the filename is) to MANIFEST.in (which 
adds the file to the sdist) and add "license_file = LICENSE" (or other 
filename) to the [metadata] section of setup.cfg (which adds the file to the 
.dist-info directory of the wheel).
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/S2HILR23CLVSJ3722PVC73V3FYCWCTZL/

Re: [Distutils] How to eliminate on part of a package?

[John Thorvald Wodder II]

On 2018 Apr 25, at 16:02, Skip Montanaro  wrote:
> I recently ported a package to Python 3. The overall structure is
> pretty straightforward:
> 
> top/
>client/
>module.py
>server/
>server.py
> 
> There's more to it, but that's enough for demonstration. I am
> retaining Python 2.7 compatibility on the client side, but have
> dispensed with that business on the server. (I run the server, not my
> users.) Accordingly, I would like the py27 version of the package to
> not have a subpackage named "server".
> 
> I thought it would be easy peasy to just trim the server bits from
> setuptools.find_packages() in my setup.py file (I have
> 36.5.0.post20170921 of setuptools), something like this:
> 
> packages = setuptools.find_packages()
> if sys.version_info.major < 3:
>packages.remove("top.server")
> 
> In either case, I pass the resulting list as the packages argument of
> setuptools.setup(...).
> 
> That doesn't work though. I get some sort of mish-mash where part of
> the top/server tree is copied, part not. I eventually get an error
> from a cp command, something about ".../server is not a directory".

If by "top/server tree" you mean that there are more subpackages under 
top.server (not just a server.py file as your diagram shows), then you need to 
filter out all of those subpackages as well, e.g.:

packages = setuptools.find_packages()
if sys.version_info.major < 3:
packages = [
pkg for pkg in packages
if pkg != "top.server" and not pkg.startswith("top.server.")
]
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Execute command before pip install

[John Thorvald Wodder II]

> On 2018 Apr 11, at 06:55, Jorge Maldonado Ventura  
> wrote:
> 
> I need to execute a command automatically when running `pip install` to solve 
> https://notabug.org/jorgesumle/boot-em-all/issues/1
> 
> I need to do that to compile the translation files. I found that overriding 
> the `setuptools.command.install` makes it work with `python3 setup.py 
> install`, but I want it to work with pip as well. Any advice or think I 
> overlooked? Is there a clean or recommended way to do this?
> 
> The whole code is free software, so you can check my `setup.py` file. The 
> repository can be cloned executing `git clone 
> https://notabug.org/jorgesumle/boot-em-all`.

This can't be done.  `pip install` installs from wheel (.whl) files, and that 
installation process currently (and, I believe, by design) has no provision for 
running arbitrary code.  You have two options:

1. Extend the `setup.py bdist_wheel` command to compile & bundle the 
translation files as part of building the wheel.  I personally don't know how 
to do this, but I believe the process is somewhat similar to extending the 
`setup.py install` command.  Note that if the compiled translation files are 
architecture-dependent, you'll also need to add the appropriate tags to the 
wheel.

2. Give your library a `boot_em_all_compile_translations` command for compiling 
the translation files, which the user must then run manually after installation.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Facing a strange issue while uploading my package using devpi

[John Thorvald Wodder II]

> On 2018 Apr 2, at 15:39, Vinay Sharma  wrote:
> 
> I am not sure if this is the right forum to ask this question. If it is not 
> then please ignore this email and point me to the right forum (if anyone 
> knows).

This might be a Python packaging problem, or it might be a devpi problem.  We 
won't know until it's solved; such is the nature of problems.

> I have a Jenkins Job to build my Python Package. At the end of this Jenkins 
> Job there are bunch of commands to upload the recently build Python Package 
> to devpi server. 
> 
> When I am trying to upload my application distribution using following 
> command "devpi upload" in Jenkins I am getting an the following error :-
> 
> my_application.tar.gz: does not contain PKGINFO, skipping

Is the "application distribution" that you're trying to upload actually an 
sdist (source distribution) or just a normal tarball?  The only kind of 
tarballs that Python package indices deal with are sdists, which are made with 
either `python setup.py sdist` (if you're using setuptools) or `flit build 
--format=sdist` (if you're using flit).

> I have checked everything and everything looks to be good like I have the 
> proper README.rst etc from which the proper PKG-INFO file should be generated.

*Is* the PKG-INFO file generated and included in the tarball, though?

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Getting dependecies of package from PyPiJSON

[John Thorvald Wodder II]

[Sending to the list this time]

On 2017 Jul 20, at 12:41, Jeremy Stanley  wrote:
> So while it might be possible to add some sort of feature
> to inspect wheels at upload and then store the specific dependencies
> declared therein and report those back via an API method, I expect
> coverage across packages in general would be fairly low today.

PyPI (both Legacy and Warehouse) actually does do this already; see the 
`requires_dist` field in, e.g., . However, 
this only seems to work if the maintainer uploads the wheel before uploading 
the sdist (unless the sdist is a .zip instead of a .tar.gz, then it can be 
uploaded first?  I'm not sure).
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Provide separate development and documentation URLs in PyPI metadata?

[John Thorvald Wodder II]

On 2017 Jun 24, at 13:34, Brett Cannon  wrote:
> When you go to PyPI.org for a project you will find a link to the "homepage". 
> Now for some projects that's their development site, e.g. GitHub URL. For 
> others it's their documentation site, e.g. Read the Docs. And not all 
> projects link to both from their PyPI page (e.g. yesterday I noticed flit 
> didn't directly link to its doc site, although Thomas fixed this when I 
> pointed it out).
> 
> So my question/idea is if it would make sense to have separate, explicit 
> development and documentation URLs in the PyPI metadata? For me that would 
> make a project's PyPI page a true homepage as I would know that no matter 
> what I could find where it's developed or where the docs are by going to 
> PyPI. This compares to now where either I gamble and go to PyPI in hopes the 
> developer provided the link there or hope I craft the right search on Google 
> (which based on my search yesterday for [Sphinx makefile] shows I don't 
> always succeed at).

The package data exposed by PyPI's JSON and XML-RPC APIs already includes a 
"docs_url" field; however, this seems to only ever be set for projects whose 
documentation is on http://pythonhosted.org with no way to point it to other 
domains.  PEP 345 defines a Project-URL field[1] that could be used to tell 
PyPI where documentation is hosted, but I'm not aware of a single tool that 
does anything with or even lets you set that field.

[1]: https://www.python.org/dev/peps/pep-0345/#project-url-multiple-use
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig