Log file Viewer

[15:46:30] <mensvaga> I'm currently reading this: https://github.com/pypa/sampleproject/ .

[15:46:39] <mensvaga> I'm aware there are project directory generation utilities, such as Cookie Cutter. It has a python project here: https://github.com/claws/cookiecutter-python-project

[15:46:58] <mensvaga> (I know they're separate projects maintained by separate groups of people). But is there anything that "aligns" https://github.com/pypa/sampleproject/ with a project directory generation utility?

[17:02:18] <toad_polo> [mensvaga](https://matrix.to/#/@freenode_mensvaga:matrix.org): I don't know of any, but the cookiecutter one is way out of date, not anywhere close to best practices. 🙁

[17:02:41] <toad_polo> sampleproject is also reasonably out of date, unfortunately.

[17:10:14] <mensvaga> Is there a sample project directory that isn't out of date?

[17:22:20] <toad_polo> Not that I know of! 😅

[18:50:11] <PSFSlack> <di> toad_polo: are there issues capturing how you think sampleproject is out of date?

[19:38:08] <toad_polo> di: Yeah, and pull requests! https://github.com/pypa/sampleproject/issues/56

[19:40:42] <toad_polo> The `setup.py check ` stuff is dicey, too, but I don't think `twine check` is a perfect replacement (though I don't know how good either of them are)

[19:42:27] <toad_polo> This is also not great, though I guess not captured in an issue? https://github.com/pypa/sampleproject/blob/52966defd6a61e97295b0bb82cd3474ac3e11c7a/setup.py#L138

[20:09:56] <mensvaga> Well, crap if my definition of a good time is drinking on a Friday, and complaining about other people's code.

[20:10:00] <mensvaga> https://github.com/pypa/setuptools/blob/1ea521c51b0ed2967a9ff1d8ad41160043a8a981/setuptools/__init__.py#L68

[20:10:19] <mensvaga> If I have a package under a parent directory that doesn't have __init__.py in it, it doesn't get picked up by that code.

[20:11:13] <mensvaga> The continue statement is too damn high up.

[20:11:27] <mensvaga> # Keep searching subdirectories, as there may be more packages

[20:11:31] <mensvaga> LIES.

[20:12:19] <mensvaga> Though, I don't know what the implications of moving that statement up would be; so, I'll have to find a work around.

[20:21:45] <toad_polo> mensvaga: `find_packages` only finds packages (not namespae packages). Any folder without an `__init__.py` is not a package in that definition, and it's not even a namespace package if it's under a folder with an `__init__.py`.

[20:21:50] <toad_polo> mensvaga: What are you trying to do?

[20:50:34] <mensvaga> Foist, I'd need to understand what the difference between a "Namespace package" and a "Package" is.

[20:51:08] <mensvaga> If a "namespace package" is a "type of package", then ... it's a package(?)

[20:51:41] <mensvaga> I'm trying to say, "Find the packages under this directory."

[20:54:52] <mensvaga> Because foo/bar/baz seems to be a thing:

[20:55:11] <mensvaga> If I have foo/bar/baz/__init__.py , it doesn't seem to find it.

[20:55:50] <mensvaga> But, if I create foo/__init__.py, foo/bar/__init__.py/ , and foo/bar/baz/__init__.py , it finds the foo/bar/baz package

[20:57:01] <mensvaga> but just having foo/var/baz/__init__.py doesn't seem to work, even though it is a "package"

[21:01:41] <toad_polo> mensvaga: What do you want to do?

[21:01:58] <toad_polo> Like why do you have packages without `__init__.py` in them?

[21:44:56] <mensvaga> Because foo might not be a "package" in my current repo, but foo/bar/baz is a package

[21:45:34] <mensvaga> Let's just say that bar is a type of foo, and baz is a type of bar. And foo and bar are maintained in different repositories.

[21:45:50] <mensvaga> Err

[21:46:01] <mensvaga> Yeah, I phrased it correctly

[21:46:08] <toad_polo> I don't know, that doesn't make sense.

[21:46:34] <mensvaga> Object inheritance doesn't make sense? What if I don't maintain the foo package in the baz repository?

[21:46:36] <toad_polo> There are two reasonable things that you would want to package up: packages in a namespace, and packages.

[21:46:54] <toad_polo> Yes, object inheritance does not make sense when "bar" and "baz" are modules.

[21:47:09] <toad_polo> "bar" and "baz" would be modules, not inherited from one another.

[21:47:19] <mensvaga> baz is a type of bar.

[21:47:22] <mensvaga> bar is a type of foo.

[21:47:43] <toad_polo> Is this an open source thing? Can I look at it?

[21:47:48] <mensvaga> Why does it not make sense that I wouldn't have the foo package defined in the bar repository?

[21:48:14] <toad_polo> It doesn't make sense for "bar" and "baz" to be inherited...

[21:48:36] <mensvaga> FOO is the thing that is inherited by bar. Bar is inherited by baz.

[21:49:29] <mensvaga> Currently it is spread across multiple repos. I use RPMs/Debian packages to install it. I was constructing the PIP example when I had these questions.

[21:49:34] <toad_polo> Well, regardless, submodules aren't usually used to indicate inheritance hierarchy.

[21:49:42] <mensvaga> So, what does?

[21:50:34] <mensvaga> And does the inheritance hierarchy need to be maintained in the same repository?

[21:50:52] <toad_polo> Inheritance hierarchy doesn't have anything to do with packaging.

[21:50:56] <toad_polo> It's a red herring.

[21:51:19] <mensvaga> Packages have classes, right?

[21:51:19] <toad_polo> You have two possible situations: you have a namespace that multiple PyPI packages can install packages into, or you have a package.

[21:52:03] <toad_polo> So for example `backports` is a namespace that a bunch of unrelated authors and repositories put their packages in. `backports.lru_cache`, `backports.zoneinfo`, etc.

[21:52:41] <mensvaga> I gtg for now, but I'll stay signed in to read your responses.

[21:52:45] <toad_polo> In Python 3 (PEP 420), those are just folders with no `__init__.py` (or *anything*) in them, and they are not installed.

[21:53:23] <toad_polo> You just create a package with the namespace in it. You use `find_namespace_packages` for that, but you should be aware that if you are not using a `src` layout, `find_namespace_packages` is annoyingly dangerous, so I strongly strongly suggest you do that.

[21:53:45] <toad_polo> If `foo` is something with classes or whatever, it needs an `__init__.py`, and if you want submodules of it, they should go in the same package.

[21:54:16] <toad_polo> Er, in the same repository and the same package.

[21:55:04] <toad_polo> There are ways around that, you can just have a second package that installs `__init__.py`, but it can cause a bunch of persnickety problems in a bunch of situations if you do it that way.

[23:33:02] <mensvaga> Thanks for the explanation. I have read it, and will email myself it, and then see what I come up with.