Might anyone know of a root place where python modules get saved to for
both python2 and 3. I assume I'm looking for all of the places where
"site-packages" can be written to.
J
---------- Forwarded message ---------
From: J A <jayro...@gmail.com>
Date: Sun, 9 Feb 2020 at 17:56
Subject: Re: Pkg iter_module for different versions of python
To: DL Neil <pythonl...@danceswithmice.info>
Ya.. perhaps it would make more sense to start with "dirty" knowledge. I.e.
a list of package/module names and then make sure they have the required
entry points, therefore "validating" that they belong to me.
Is there a valid directory structure to start from that is universal?
perhaps from there I could parse through site-packages/**/MODULE_name.whl
or something?
and yes no more python 2 however a few of my commands are/were wrapping
third party tool api's that are python 2 :/
J
On Sun, 9 Feb 2020 at 17:05, DL Neil via Python-list <python-list@python.org>
wrote:
> On 10/02/20 4:46 AM, J A wrote:
> > as a sysadmin I've written several small tools as python command line
> apps
> > that get installed with python setup.py install. I would now like to
> create
> > another tool that would quickly list out all of my custom tools that may
> be
> > installed on the system. so that others can get a quick menu of what
> > commands are available. I believe I have a working app that uses the
> > iter_modules function to list out all of the names and then I just filter
> > based on names that I know to be mine.
> >
> > My problem.. This works if everyone of my tools is only written in
> python 3
> > or 2, but not both. Are there any tricks to getting iter_modules to
> return
> > both python 3 and 2 installed modules?
>
>
> Is the issue with iter_modules?
>
> Remember that different Python versions are installed with separate
> libraries/paths. Accordingly, this lap-top's /usr/lib64 has both
> python2.7/ and python3.7/ sub-directories.
>
> When an application is running under one* or the other, the sys.path
> changes accordingly (assuming the pkgutil.iter_modules(path=None) option).
>
> (in case needed) Remember also that different installation methods may
> install packages in different directories anyway, eg personal
> installation or system-wide. So, even 'this' sys.path may not reveal
> what is present on 'this system'.
>
> Might it be worth reversing the strategy and starting from a list of
> your modules, search likely portions of the directory-structure for
> 'your stuff'?
> (from a perspective of complete ignorance of the problem domain)
>
> * requisite notice about not using deprecated Python2.n these days!
> ("Do as I say, but not as I do"? I suspect/hope that this system's 2.7
> is 'legacy' and no longer used for anything, including the OpSys)
> --
> Regards =dn
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
