setup.py imports its own package "sample" about sampleproject HOT 23 CLOSED

the "wreak havoc" comment in the SO is not necessarily true, i think only true if the import involves importing dependencies, but yes, that should at least be mentioned.

Note the commit 335acdc includes a link to http://packaging.python.org/en/latest/tutorial.html#version, which gives more detail and gives 2 non-import examples.

I'll take another crack at updating both the sampleproject and the PPUG later tonight.

The PPUG can be more open and mention various alternatives, but the sampleproject has to do it one way. I'm partial to the read/exec technique, but otoh the VERSION file is nice because of the "even non-Python languages that may need access to the version string" argument.

from sampleproject.

I'd be happiest to just see it as a string. metadata should go away from being import magic, designed to be consumed as executable code, to being static, parseable data, readable by any tool.

from sampleproject.

Yeah, I'm coming to feel that this is all a lot of complexity to avoid repeating a simple number. Just hard-code it. After all, the plan is to ultimately move away from an executable setup.py altogether.

Anyone who worries about the duplication could write a simple script to set a new version in setup.py and pkg/__init__.py and/or a checking script that makes sure the two values are the same, which they run before a release.

from sampleproject.

All comments above make excellent points. This seems like an insufficient tooling/bootstrap problem.

Anyone who worries about the duplication could write a simple script to set a new version in setup.py and pkg/__init__.py and/or a checking script that makes sure the two values are the same, which they run before a release.

It seems like @warner has tried to come up with something along these lines called versioneer. I just discovered it so I don't know how it, itself, gets around the bootstrapping problem.

from sampleproject.

After all, the plan is to ultimately move away from an executable setup.py altogether.

I don't think that's necessarily needed; certainly, metadata should be moved away from the executable build process, and versions are a prime example of that. There's not such a strong argument for the build process itself, though. Some project will always find a way to need to be more complex than a tooling that builds off a declarative configuration, IMHO, and this is even more-so the case with python than with a more rigid compiling language like java that still manages to have massively complex build tools just to consume swaths of xml in order to allow people flexible build configuration.

from sampleproject.

I don't think long term we'll have an executable setup.py. That doesn't mean we have a static/declartive build system but rather it would just work differently.

from sampleproject.

It seems like @warner has tried to come up with something along these lines called versioneer. I just discovered it so I don't know how it, itself, gets around the bootstrapping problem.

In Versioneer, setup.py imports versioneer.py, which asks git (or some other VCS, once we get support for them) what version string it ought to use. A second copy is put into the source tree (as _version.py), so runtime code can ask the same question. When you do a build (setup.py build/install/sdist), _version.py is replaced by a pre-computed static string, so you don't have to run git unless you're in the original source tree.

So yeah, setup.py doesn't import your source code: I've had bad experiences with that too. It also doesn't modify your source tree, which is nice (I've also had problems with systems that give you a "setup.py update-version" command, which I always forget to run, so version numbers get stale).

from sampleproject.

There's a tension here. On the one hand, as this project is linked from the PUG, it should be a good tutorial. On the other hand, as code people will copy it needs to be robust and reliable. The original code (reading __init__.py) was written for reliability, because people told me that importing the package in setup.py had problems. But it's terrible tutorial code, as it's complex and it needs to be written in a style that works on Python 2 and 3.

I think that in order to resolve this issue, we need to decide which role the project should focus on.

I'm of the opinion that writing 100% robust setup.py code is hard, and reinventing the wheel here probably isn't a good idea (there are projects like cookiecutter that offer much more full-featured templates). So I'd rather that this project become a tutorial-level example.

As such, I think that simply repeating the version number in setup.py and __init__.py (with short comments cross-referencing the two) is sufficient here.

Hard-coded versions are simple to understand. And they don't run the risk (which importing the package does) of looking like it's a full-featured solution while actually having issues that could become important as the project grows.

from sampleproject.

I'm inclined to go with Paul on this (partly due to sheer frustration with the whole topic), with comments that link to the PPUG which will run down various options with pros and cons and links. I'll probably just push the change directly to the sampleproject, but post a PR for the PPUG.

from sampleproject.

@pfmoore said:

After all, the plan is to ultimately move away from an executable setup.py altogether.

A perennial hope that despite years of effort still hasn't become reality, unfortunately.

As such, I think that simply repeating the version number in setup.py and init.py (with short comments cross-referencing the two) is sufficient here.

Hard-coded versions are simple to understand. And they don't run the risk (which importing the package does) of looking like it's a full-featured solution while actually having issues that could become important as the project grows.

Agreed, along with @qwcode's suggestion of

with comments that link to the PPUG which will run down various options with pros and cons and links.

from sampleproject.

There's another excellent option, which is to only include the version in setup.py and not include the version # in __init__.py at all.

from sampleproject.

That's not a particularly great option, it makes it hard to tell what version of code is being imported.

from sampleproject.

Just use the pkg_resources api like everyone else! :P

from sampleproject.

That doesn't tell you anything about what code you're importing. That tells you what code pkg_resources thinks is installed.

from sampleproject.

I'm willing to have most of my code assume it has been installed
correctly... sure, the code could duplicate the work of pkg_resources
and check all of its installed dependencies' versions against what it
says in install requirements, but who has the time?

On Mon, May 19, 2014, at 08:49 AM, Donald Stufft wrote:

That doesn't tell you anything about what code you're importing.
That tells you what code pkg_resources thinks is installed.

—

Reply to this email directly or [1]view it on GitHub.
[208018__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxNjEyMjk1OS
wiZGF0YSI6eyJpZCI6MzIzNTU3NDN9fQ==--d575bcad598b9d0c37683cefe80988c364c
5e3f6.gif]

References

1. #11 (comment)

from sampleproject.

Most people have no reason to have pkg_resources check the versions at runtime (nor do they have any reason to do that check). In fact that check has often times lead to failures in the real world because pkg_resources gets confused about which version is installed.

from sampleproject.

Sure, the question is : what business does your code have checking the
versions of its dependencies at all? It's just a waste of time.

On Mon, May 19, 2014, at 09:20 AM, Donald Stufft wrote:

Most people have no reason to have pkg_resources check the versions
at runtime (nor do they have any reason to do that check). In fact
that check has often times lead to failures in the real world
because pkg_resources gets confused about which version is
installed.

—

Reply to this email directly or [1]view it on GitHub.
[208018__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxNjEyNDgzNS
wiZGF0YSI6eyJpZCI6MzIzNTU3NDN9fQ==--a42ae149df1054e9fa966945efa619ca605
316f5.gif]

References

1. #11 (comment)

from sampleproject.

The version in __init__.py isn't hardly ever used for checking versions of dependencies. It's typically a debugging aid in order to report what version of something you're using. For instance pip uses pip.__version__ to populate pip --version.

from sampleproject.

@dstufft wrote

Most people have no reason to have pkg_resources check the versions at runtime (nor do they have any reason to do that check). In fact that check has often times lead to failures in the real world because pkg_resources gets confused about which version is installed.

I have worried about this myself but I have not seen a concrete example. Is there a documented, reproducible case for this? I have wanted to use the pkg_resources as suggested by @dholth in my own projects but have hesitated because of this claim.

from sampleproject.

The simplest way of making it fail is by installing a project and then doing PYTHONPATH=path/to/a/checkout. This isn't pkg_resources getting confused however it can often be triggered by the implicit "." on sys.path.

The cases where pkg_resources actually get confused typically involve several install/uninstall stops and I don't know that anyone has ever tracked down exactly why it happens. Normally I think it tends to be a result of mixing easy_install and pip plus some unknown factor.

from sampleproject.

On Mon, May 19, 2014, at 03:46 PM, Donald Stufft wrote:

The simplest way of making it fail is by installing a project and
then doing PYTHONPATH=path/to/a/checkout. This isn't pkg_resources
getting confused however it can often be triggered by the implicit
"." on sys.path.

The cases where pkg_resources actually get confused typically
involve several install/uninstall stops and I don't know that anyone
has ever tracked down exactly why it happens. Normally I think it
tends to be a result of mixing easy_install and pip plus some
unknown factor.

"Chemical X"

—

Reply to this email directly or [1]view it on GitHub.
[208018__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxNjE0Nzk2MC
wiZGF0YSI6eyJpZCI6MzIzNTU3NDN9fQ==--5f55e3819ad303fd2f62e7ead23f66fdf96
5b171.gif]

References

1. #11 (comment)

from sampleproject.

see 2 PRs:

• sampleproject: #14
• ppug: pypa/packaging.python.org#55

from sampleproject.

Solved now thanks to @qwcode's commits above

from sampleproject.