3 ms·

Weird post. It raises questions, then admonishes you for reading them. > "Well you're not supposed to get core dumps from versions with uncommitted changes, un

Weird post. It raises questions, then admonishes you for reading them. > "Well you're not supposed to get core dumps from versions with uncommitted changes, unless it's your local version that you haven't given to anyone but are testing locally, so you know which version it is. You should only release versions externally thru CI" - so giving anything to anyone to test is now considered "releasing externally" and must necessarily go thru CI, and having trouble finding the source code is now a punishment for straying from proper procedure? How did this discussion, which started at how build caches speed up the build, deteriorate to the point where we're telling developers to change how they work, in ways which will slow them down? Hey, you brought it up. Don't put this on the reader.

crabbone 3y ago
I'm not the author, but I think, I understand what this is about. It's the etiquette rather than the law. This is about bad situations like... here are some examples: * If you read the description of Wheel format (Python packages), the name of the archive allows one to include eg. build number in it, but states such packages shouldn't be released publicly. (I've never tested this with PyPI.org, but wouldn't be surprised if they actually allow such packages, because see next). * PyPI allows uploading packages with non-release versions, i.e. X.Y.Za1 or X.Y.Zb2 or X.Y.Zrc3. That is the public index intended for production use allows non-production versions. This usually doesn't bother Python programmers because they rarely use anything other than pip to install packages, whose crafty defaults allow to filter out non-released versions. This, of course, breaks when easy_install gets into the picture (and that happens when developers run something like "setup.py install"). Now, where this is all going: the protocol for working with publicly released software should include the release versions (if you want to debug it, send bug reports etc.) This is to prevent from overloading maintainers with investigation of custom configurations and the infinite number of things users could do with the software when not following the explicit usage / build instructions. You, among friends, don't have to follow the protocol, as long as your friends are OK with it. But, as a general advise, OP is right, this is how you behave nicely, and if you don't do that the users will be upset, and you'll get a lot of extra work with a ton of criticism on top of it.
- yosefk 3y ago
  My point in the quote from GP was that it should be easy to debug any binary, whether it was built in CI or locally, as a formal release or not, and whether it did or didn't include uncommitted changes. Refix will make your binaries easily debuggable in all these cases regardless of how your build system and version control (or several build and version control systems) works.

crabbone 3y ago

I'm not the author, but I think, I understand what this is about. It's the etiquette rather than the law. This is about bad situations like... here are some examples: * If you read the description of Wheel format (Python packages), the name of the archive allows one to include eg. build number in it, but states such packages shouldn't be released publicly. (I've never tested this with PyPI.org, but wouldn't be surprised if they actually allow such packages, because see next). * PyPI allows uploading packages with non-release versions, i.e. X.Y.Za1 or X.Y.Zb2 or X.Y.Zrc3. That is the public index intended for production use allows non-production versions. This usually doesn't bother Python programmers because they rarely use anything other than pip to install packages, whose crafty defaults allow to filter out non-released versions. This, of course, breaks when easy_install gets into the picture (and that happens when developers run something like "setup.py install"). Now, where this is all going: the protocol for working with publicly released software should include the release versions (if you want to debug it, send bug reports etc.) This is to prevent from overloading maintainers with investigation of custom configurations and the infinite number of things users could do with the software when not following the explicit usage / build instructions. You, among friends, don't have to follow the protocol, as long as your friends are OK with it. But, as a general advise, OP is right, this is how you behave nicely, and if you don't do that the users will be upset, and you'll get a lot of extra work with a ton of criticism on top of it.

yosefk 3y ago
My point in the quote from GP was that it should be easy to debug any binary, whether it was built in CI or locally, as a formal release or not, and whether it did or didn't include uncommitted changes. Refix will make your binaries easily debuggable in all these cases regardless of how your build system and version control (or several build and version control systems) works.