Re: versioning, here’s the situation: pypi has a version of 0.0.0, but the github repo has no official version number or even tags, and it’s not clear which commit the pypi version has used.
I prefer to build from a github repo because it contains tests and other useful things that the pypi distribution doesn’t have. In this situation, I specified the commit hash, set the version to be consistent with pypi’s, and set the revision to be the github commit date. Is there another preferred way in this situation? Magenta just migrated to tf2, still depends on deprecated packages like tensor2tensor, and I expect will be pretty dynamic for a bit. Yet it has working capabilities now that are useful to get under install/version control. > On Jul 4, 2020, at 10:03, Ryan Schmidt <[email protected]> wrote: > > > > On Jul 3, 2020, at 14:23, Steven Smith wrote: > >>> revision 20200622 > > revision should be 0. > > >>> version 0.0.0 > > version should probably be 20200622, unless they have a real version number. > > >>> test.env-append \ >>> "PATH=$env(PATH):${workpath}/bin" \ > > Don't you want your ${workpath}/bin to precede what's already in $env(PATH)? > > > On Jul 3, 2020, at 19:40, Steven Smith wrote: > >> Running the basic build command by hand yields a successful build: >> >>> /opt/local/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7 >>> setup.py --no-user-cfg build -j12 >> >> This suggests that one of the environment variables is causing the issue. > > No, it suggests that when you run it by hand, you're not benefitting from the > features of the python portgroup, one of which is to ensure that you've > specified your python module dependencies correctly by preventing them from > being automatically downloaded. > > >> How does one remove all environment variables from the build phase? > > You don't do that. > > >> Simply invoking >> >> build.env >> >> doesn’t change anything > > Correct. >
smime.p7s
Description: S/MIME cryptographic signature
