# Determining top-level import package names programmatically

**URL:** <https://discuss.python.org/t/determining-top-level-import-package-names-programmatically/45055>\
**Category:** Python Help\
**Tags:** packaging-help\
**Created:** [February 2, 2024, 8:33pm UTC](https://discuss.python.org/t/determining-top-level-import-package-names-programmatically/45055 "2024-02-02T20:33:39Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![cameron](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cameron/32/2658_2.png) [@cameron](https://discuss.python.org/u/cameron)\
**Post date:** [February 4, 2024, 9:35pm UTC](https://discuss.python.org/t/determining-top-level-import-package-names-programmatically/45055/7 "2024-02-04T21:35:38Z")

</div>

> > [@Any list of well-known distribution/import name mismatches?](https://discuss.python.org/t/any-list-of-well-known-distribution-import-name-mismatches/44733/18):
> >
> > Shouldn’t this be something that someone with access to PyPI’s db could  
> > answer with a query?
> 
> [… things which require inspecting (and therefore _fetching_) wheels and sdists …]

That sounds cumbersome.

> > [@kknechtel](#):
> >
> > As far as I can tell, core metadata doesn’t store that kind of information about top-level package names,
> 
> It has been  
> [proposed](https://discuss.python.org/t/record-the-top-level-names-of-a-wheel-in-metadata/29494)  
> (which also includes some discussion of how one can extract that  
> currently, including in a scenario such as this).

I’m increasingly of the opinion that this _should_ be queryable  
(“queriable”?) for the following reason: malice.

I’m about half way through the discussion cited above and it’s all  
“would this be useful?” and “where might we put this?” and “what should  
be in it?” and not even an allusion to malicious packages until  
[here](https://discuss.python.org/t/record-the-top-level-names-of-a-wheel-in-metadata/29494/33),  
which is pretty short.

We’ve got an existing problem with typosquatting on project names. What  
about innocuous PyPI project name which install their innocuous trite  
package and _also_ something malicious as a well known name (or close  
typo)?

Having this at the top level in a queriable form lets us:

- show what a project installs, import-wise
- allow various sweeps of projects for conflicts and/or malice
- have the installers (wheel unpackers etc) _validate_ what’s being  
installed against what is _supposed_ to be being installed, and  
_reject_ installs not matching their spec

---

_[View the full topic](https://discuss.python.org/t/determining-top-level-import-package-names-programmatically/45055)._
