Log file Viewer

[09:16:15] <tzickel> pombreda: exactly, github README.md makes anchors, PyPI doesn't ....

[19:15:51] <mensvaga> If I was able to build the distribution package as per this: https://packaging.python.org/tutorials/packaging-projects/

[19:16:05] <mensvaga> How do I install the package without uploading it to test.pypi.org ?

[19:16:27] <mensvaga> (Can I get pip to install the package from local files?)

[19:30:28] <toad_polo> [mensvaga](https://matrix.to/#/@freenode_mensvaga:matrix.org): `pip install <directory>`

[19:30:57] <mensvaga> toad_polo: Thanks. By the way, find_namespace_packages() was what I was looking for. I use "src" style layouts.

[19:31:28] <toad_polo> Cool cool.

[19:40:57] <mensvaga> toad_polo: what directory? When I specify the "dist" directory, I get a long list of errors

[19:41:13] <toad_polo> [mensvaga](https://matrix.to/#/@freenode_mensvaga:matrix.org): pip install .

[19:41:32] <toad_polo> The root directory that contains `pyproject.toml`

[19:42:40] <mensvaga> I don't have one of those; I followed https://packaging.python.org/tutorials/packaging-projects/

[19:42:57] <toad_polo> If you want to install something you have built using `build` or `pep517.build`, then you pip install the artifact (`.whl` or `tar.gz`)

[19:43:00] <mensvaga> Could be how I'm running pip though; I need to look at things

[19:43:18] <mensvaga> I'm using "python3 -m pip install ."

[19:43:18] <toad_polo> If it doesn't have pyproject.toml, that guide is super out of date.

[19:43:40] <mensvaga> Who maintains packaging.python.org?

[19:43:48] <toad_polo> That should work, if you are in the project root directory.

[19:44:20] <toad_polo> I dunno these days.

[19:44:42] <toad_polo> It's the official guide, but as an organization PyPA is probably worst at documentation.

[19:45:18] <mensvaga> *sigh* OK; might have found a "bug"

[19:45:32] <mensvaga> I have a script, bin/some_script.py .

[19:45:39] <mensvaga> bin/ is a symbolic link

[19:46:02] <mensvaga> It complains about not being able to find bin/some_script.py

[19:46:14] <mensvaga> when I copy the directory, it works.

[19:46:29] <mensvaga> lib, on the other hand seems to work fine when it's a symbolic link.

[19:48:31] <mensvaga> It seems I'm able to build it just fine. But when I try to "install" it from the current directory it doesn't like it.

[20:14:27] <mensvaga> Does that sound like something that's worth submitting a bug over?

[20:15:45] <mensvaga> scripts=['bin/some_script.py'], can not refer to a directory that's a symbolic link

[20:23:19] <mensvaga> When I do scripts=['

[20:24:45] <mensvaga> scripts=['../../src/bin/some_script.py'] It also says: No such file or directory: '../../src/bin/some_script.py' , even though the file exists. I wonder if it's looking for it relative to a different directory

[20:25:38] <mensvaga> (but it's strange how the packages directive doesn't seem to have this issue.

[20:27:08] <toad_polo> Why do you have up-references like that?

[20:27:11] <mensvaga> Yep. That's it. "scripts" can't refer to files outside of the project directory. packages can.

[20:27:21] <mensvaga> This isn't the ONLY thing I'm building from the repo.

[20:27:29] <toad_polo> I'm pretty sure that those paths are relative to the for directory.

[20:28:50] <toad_polo> Anything that works with up-references like that is a bug. All of it should be broken, and you should probably report it to setuptools if it does work.

[20:29:09] <mensvaga> So this builds fine when I have a symlink to bin/ and a symlink to lib: python3 setup.py sdist bdist_wheel

[20:29:34] <mensvaga> Running "python3 -m pip install ." breaks when bin/ is a symbolic link.

[20:29:52] <mensvaga> I don't understand why it should break...

[20:37:01] <toad_polo> mensvaga: Probably what's happening is that `bin` is a symbolic link to a relative location.

[20:37:41] <toad_polo> So if you were to build a source distribution you'd have a broken symlink sitting there.

[20:37:59] <toad_polo> Unpack it to some random location and try to do the build and obviously it will fail.

[20:38:23] <toad_polo> `pip install .` actually copies the local directory into a temporary location and does the build there, to avoid having the build process leave around undesirable artifacts.

[20:38:34] <toad_polo> So your symlink gets broken.

[20:39:11] <toad_polo> It would work if the symlink were an absolute symlink to the full path on disk, but obviously you can't check that in to a git repository, and it's not something you can distribute in an sdist.

[20:54:16] <pombreda> pombreda

[20:54:24] <pombreda> fat fingers

[21:39:10] <mensvaga> I can either:

[21:39:32] <mensvaga> copy the library directory, and bin directory into some transient location under the python project directory, and make the pip packages / source dists out of that

[21:40:17] <mensvaga> (using something like make), or, I can do the symbolic linking; and have the "sdist" be generated as a result of a copy with all symbolic links resolved.

[21:41:09] <mensvaga> I'll have to read up on "sdist"s now to see...

[21:43:21] <mensvaga> https://docs.python.org/3/distutils/sourcedist.html is what I'll read next.

[21:47:54] <toad_polo> I would basically caution you that non-standard code layouts like mono-repo type situations and other weird stuff like that is very likely to be unsupported.

[21:50:53] <toad_polo> If you hack something together, it might work today but if you are not careful to make your hack entirely out of parts that are documented parts of the public API, there's a not-insignificant chance that your workflow will get broken by future updates, and when you raise an issue about it you'll be met with, "That's not a supported configuration, so... wontfix."

[21:52:23] <toad_polo> Not saying there are never good reasons for that sort of thing, just that packaging is constantly in flux (hence all the outdated documentation — note that the `distutils` documentation you link to is also unmaintained and has a warning to that effect at the top of the page `setup.py <anything>` is definitely not the "right" way to do things).

[21:53:30] <toad_polo> So you may want to seriously consider how important it is for you to have some convoluted multi-package repository instead of multiple small repositories.

[21:55:13] <toad_polo> A lot of times when people try and symlink something in or use git submodules, they're better off breaking up their bigger package into something smaller, so instead of `bin/` symlinking to some directory on disk, you have a dedicated `my-script` package and have anything that was symlinking it depend on that `my-script` package.