SCons 3.0.0 release
SCons - a software construction tool Release Notes This is SCons, a tool for building software (and other files). SCons is implemented in Python, and its "configuration files" are actually Python scripts, allowing you to use the full power of a real scripting language to solve build problems. You do not, however, need to know Python to use SCons effectively. Please go to http://scons.org/pages/download.html to get the latest production release of SCons. If you have current pip and virtualenv versions, you can install scons into a virtualenv using: pip install scons (For the time being installing outside a virtualenv via pip may fail as we have some oustanding issues related to such installs.) So that everyone using SCons can help each other learn how to use it more effectively, please go to http://scons.org/lists.html#users to sign up for the scons-users mailing list. RELEASE 3.0.0 - Mon, 18 Sep 2017 08:32:04 -0700 Please consult the RELEASE.txt file for a summary of changes since the last release and consult the CHANGES.txt file for complete a list of changes since last release. This announcement highlights only the important changes. Please note the following important changes since release 2.5.1: This is the initial release supporting both python 3.5+ and 2.7.x and pypy There are some important changes: - Any print statements must now use python 3 syntax of "print()" - All node content should be in bytes. This is the default in python 2.7.x, in Python 3 all strings are by default unicode. byte and/or bytearray should be used if you construct content for return by a custom node type's get_content() method. - There are some (as yet unresolved issue) using Literal()'s in some context with Python 3 - pypy should be supported, please report any issues to the user's mailing list. - Currently if you switch back and forth between python 2.7.x and 3.5+ you will need to remove your sconsign file. This should be resolves shortly, but regardless switching between python 2.7.x and 3.5+ will not use compatible sconsigns and as such incremental builds should be expected to rebuild anything changed since the previous scons run with the same version of python. - It is likely that migrating from 2.5.1 -> 3.0.0 alpha will cause rebuilds due to the significant number of changes in the codebase. - Removed deprecated tools CVS, Perforce, BitKeeper, RCS, SCCS, Subversion. - Removed deprecated module SCons.Sig - See CHANGES.txt for more details on other changes - 3.0.0 should be slightly faster than 2.5.1. Changes yielded a 15% speed up for null incremental builds. - Updated D language scanner support to latest: 2.071.1. - python -m SCons should now run SCons if it's installed PYTHONPATH -- https://mail.python.org/mailman/listinfo/python-list
Re: Issues with pip installation on windows
try using: python -m pip Does that work? On Tue, Sep 19, 2017 at 12:47 PM, Joey Steward wrote: > -- Forwarded message -- > From: Joey Steward > Date: Mon, Sep 18, 2017 at 3:26 PM > Subject: Issues with pip installation on windows > To: python-list@python.org > > > Hello, > > I'm a new programmer who initially began learning python for bioinformatics > and data analysis applications, but have recently become interested by web > development so I've set out to learn django. > > I used to use an ubuntu operating system when I was previously learning > some aspects of bioinformatics but recently switched to a new computer with > windows 10. I've been trying to use pip but continue getting an error > message on the command line when I try to use pip (basically saying pip > isn't a recognized command). > > I have been checking that pip installed though and up to date with the > version of the python download I'm using ( was trying 3.6 and then switched > to 2.7) so I feel it has something to do with how I have the setup that pip > isn't being recognized, but I haven't been able to find any solutions with > google searches. > > Is there any info out there that'd be good for a novice to check out to > solve this? > > If so would greatly appreciate it! > > All the best, > > Joey Steward > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: automated comparison tool
Use Git... at least you get can back what used to work.. On Tue, Sep 20, 2016 at 2:20 PM, Andrew Clark wrote: > On Tuesday, September 20, 2016 at 3:25:11 PM UTC-5, Lawrence D’Oliveiro > wrote: > > On Wednesday, September 21, 2016 at 7:44:22 AM UTC+12, Andrew Clark > wrote: > > > If anyone can help me out with sudo code or set me in the right > direction > > > would be nice. > > > > You know What Aesop said: “the gods* help those who help themselves”. > Start by posting an initial stab at your code for solving, if not the whole > problem, at least part of it. > > > > *for “gods”, read “peanut gallery”. They’ll be falling over themselves > to critique every little shortcoming, real or otherwise, in the code you > post. > > Thanks. I've restarted my code so many times i no longer have a working > version of anything. I'm trying to get the "go to remote directory" part to > get files done first. > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
SCons 2.5.1 Released
Available at: https://sourceforge.net/projects/scons/files/latest/download?source=files Changelog: SCons - a software construction tool Change Log RELEASE 2.5.1 - Mon, 03 Nov 2016 13:37:42 -0400 From William Deegan: - Add scons-configure-cache.py to packaging. It was omitted From Alexey Klimkin: - Use memoization to optimize PATH evaluation across all dependencies per node. (PR #345) RELEASE 2.5.0 - Mon, 09 Apr 2016 11:27:42 -0700 From Dirk Baechle: - Removed a lot of compatibility methods and workarounds for Python versions < 2.7, in order to prepare the work towards a combined 2.7/3.x version. (PR #284) Also fixed the default arguments for the print_tree and render_tree methods. (PR #284, too) From William Blevins: - Added support for cross-language dependency scanning; SCons now respects scanner keys for implicit dependencies. - Notes for SCons users with heterogeneous systems. - May find new (previously missed) dependencies. - May cause rebuild after upgrade due to dependency changes. - May find new dependency errors (EG. cycles). - Discovered in some of the SCons QT tests. - Resolved missing cross-language dependencies for SWIG bindings (fixes #2264). - Corrected typo in User Guide for Scanner keyword. (PR #2959) - Install builder interacts with scanner found in SCANNERS differently. - Previous: Install builder recursively scanned implicit dependencies for scanners from SCANNER, but not for built-in (default) scanners. - Current: Install builder will not scan for implicit dependencies via either scanner source. This optimizes some Install builder behavior and brings orthogonality to Install builder scanning behavior. From William Deegan: - Add better messaging when two environments have different actions for the same target (Bug #2024) - Fix issue only with MSVC and Always build where targets marked AlwaysBuild wouldn't make it into CHANGED_SOURCES and thus yield an empty compile command line. (Bug #2622) - Fix posix platform escaping logic to properly handle paths with parens in them "()". (Bug #2225) From Jakub Pola: - Intel Compiler 2016 (Linux/Mac) update for tool directories. From Adarsh Sanjeev: - Fix for issue #2494: Added string support for Chmod function. From Tom Tanner: - change cache to use 2 character subdirectories, rather than one character, so as not to give huge directories for large caches, a situation which causes issues for NFS. For existing caches, you will need to run the scons-configure-cache.py script to update them to the new format. You will get a warning every time you build until you co this. - Fix a bunch of unit tests on windows -- https://mail.python.org/mailman/listinfo/python-list
Re: please test the new PyPI (now in beta)
The back ground blue on the pypi page is the highlight blue on the python.org page, they should change the color to match to background python.org color. -Bill On Tue, Mar 27, 2018 at 7:50 AM, Steven D'Aprano < steve+comp.lang.pyt...@pearwood.info> wrote: > On Tue, 27 Mar 2018 22:25:44 +1100, Chris Angelico wrote: > > > On Tue, Mar 27, 2018 at 9:49 PM, Steven D'Aprano > > wrote: > >> As an extra bonus, even when searching is not reliant on Javascript, > >> mangling the text in the search box often is, so unless I'm extra > >> careful, whenever I want to search for (say) "aardvarks", I invariably > >> end up searching for "searaardvarksch". > >> > >> At least the new PyPI search box is better than that. They get a point. > >> > >> > > "Mangling the text" should never be necessary. The HTML5 tag has > > a 'placeholder' attribute for a reason. > > > You're assuming the page is using HTML5. I've used a lot of these that > did it in Javascript, and didn't degrade gracefully if Javascript was > disabled. > > > > -- > Steve > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: please test the new PyPI (now in beta)
Re color. Would the python.org background color (which is darker) work? To my eyes the background on pypi looks like the highlight color on python.org (I've said this earlier, but just curious if that's what others see as well) On Thu, Mar 29, 2018 at 2:33 PM, Ethan Furman wrote: > On 03/29/2018 11:01 AM, Sumana Harihareswara wrote: > >> On Wednesday, March 28, 2018 at 10:48:52 AM UTC-4, Ethan Furman wrote: >> > > The new PyPI lists of projects wastes too much space, and the bright blue >>> >> >> is intolerable. I can't use it. > >> >> When you say the bright blue is intolerable, I presume it hurts your eyes >> > > -- is that right? > > That is correct. > > Color calibration varies across monitors, some people are sensitive to >> > > certain shades of light, etc., so I want to let the designer know more, > > and ask about it in user testing. > > For me it's a matter of brightness; bright colors should be used as > accents, not as the main course. > (IMHO, of course ;) > > You probably know that, in a real pinch, you can turn off styling entirely >> > > for a site in your browser, but I would prefer that you not have to do > that. > > I am vaguely aware of that, but my typical response to such web sites is > to not use them. > > Are the little boxes replaceable by the package authors? That would be >>> interesting. >>> >> >> I think you're talking about https://github.com/pypa/wareho >> use/issues/2211 - >> > > if/when we implement that, project logo images could show up on the > project > > detail pages, and in search results and similar listings, instead of the > > white cube. > > Cool, looking forward to it! > > > -- > ~Ethan~ > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: www.python.org down
Ditto. I see a 502. On Mon, Apr 30, 2018 at 1:38 PM, Jorge Gimeno wrote: > Not sure who to report to, but the site comes back with a 503. Anyone know > where I can direct this to? > > -Jorge L. Gimeno > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: www.python.org down
Still 502 for me. On Mon, Apr 30, 2018 at 2:17 PM, Paul Moore wrote: > It's working for me now. > Paul > > On 30 April 2018 at 18:38, Jorge Gimeno wrote: > > Not sure who to report to, but the site comes back with a 503. Anyone > know > > where I can direct this to? > > > > -Jorge L. Gimeno > > -- > > https://mail.python.org/mailman/listinfo/python-list > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: www.python.org down
back up for me. On Mon, Apr 30, 2018 at 2:26 PM, Mark Lawrence wrote: > On 30/04/18 19:17, Paul Moore wrote: > >> It's working for me now. >> Paul >> >> On 30 April 2018 at 18:38, Jorge Gimeno wrote: >> >>> Not sure who to report to, but the site comes back with a 503. Anyone >>> know >>> where I can direct this to? >>> >>> -Jorge L. Gimeno >>> -- >>> https://mail.python.org/mailman/listinfo/python-list >>> >> > When originally reported I was getting, and am still getting, 502. > > -- > My fellow Pythonistas, ask not what our language can do for you, ask > what you can do for our language. > > Mark Lawrence > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] [RELEASE] Python 2.7.15
Is it possible to get the release notes included on the download page(s)? On Tue, May 1, 2018 at 10:35 AM, Guido van Rossum wrote: > Simple. I misread "latest" for "last" and was hopeful that no new bugs > would need to be fixed between now and 2020. I will post a correction on > Twitter now. > > On Tue, May 1, 2018 at 2:58 AM, Alex Walters > wrote: > > > I've gotten some mixed signals on the status of this release, notably > from > > the BDFL: > > > > https://twitter.com/gvanrossum/status/991170064417153025 > > "Python 2.7.15 released -- the last 2.7 release!" (and a link to this > > thread) > > > > I was under the impression that 2.7 was being supported until 2020. If > > this > > is the final release of 2.7, what would "support" constitute? My > > assumption > > was that the final release of 2.7 would be sometime in 2020 (or much > closer > > to 2020 than 19 months). > > > > > -Original Message- > > > From: Python-Dev > > list=sdamon@python.org> On Behalf Of Benjamin Peterson > > > Sent: Tuesday, May 1, 2018 12:10 AM > > > To: python-list@python.org; python-annou...@python.org; python- > > > d...@python.org > > > Subject: [Python-Dev] [RELEASE] Python 2.7.15 > > > > > > Greetings, > > > I'm pleased to announce the immediate availability of Python 2.7.15, > the > > > latest bug fix release in the senescent Python 2.7 series. > > > > > > Source and binary downloads may be found on python.org: > > > > > > https://www.python.org/downloads/release/python-2715/ > > > > > > Bugs should be reported to https://bugs.python.org/ > > > > > > The source tarball contains a complete changelog in the Misc/NEWS file. > > The > > > only change since the release candidate is a fix for undefined C > behavior > > that > > > newer compilers (including GCC 8) have started to exploit. > > > > > > Users of the macOS binaries should note that all python.org macOS > > installers > > > now ship with a builtin copy of OpenSSL. Additionally, there is a new > > > additional installer variant for macOS 10.9+ that includes a built-in > > version of > > > Tcl/Tk 8.6. See the installer README for more information. > > > > > > Happy May, > > > Benjamin > > > 2.7 release manager > > > ___ > > > Python-Dev mailing list > > > python-...@python.org > > > https://mail.python.org/mailman/listinfo/python-dev > > > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > tritium- > > > list%40sdamon.com > > > > ___ > > Python-Dev mailing list > > python-...@python.org > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > > guido%40python.org > > > > > > -- > --Guido van Rossum (python.org/~guido) > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Splitting up large python module impact on performance?
Greetings, I'm doing some refactoring on a fairly large python codebase. Some of the files are > 4000 lines long and contain many classes. Should I expect any performance hit from splitting some of the classes out to other files? Thanks, Bill -- https://mail.python.org/mailman/listinfo/python-list
Re: Google weirdness
I also got such. I'm guessing your track record of searches has flagged you as someone they might want to hire. On Fri, Jul 13, 2018 at 5:36 AM, Steven D'Aprano < steve+comp.lang.pyt...@pearwood.info> wrote: > On Thu, 12 Jul 2018 22:31:35 -0400, Travis McGee wrote: > > > I somehow managed to trigger the dialog below by typing in a certain > > Python phrase to Google. > > Is the phrase a secret? > > > > Anyone know what it's about? > > My guess is that either: > > 1) You have accidentally discovered a back door through Google's > firewalls and security, and now have total control over their entire > network of tens of thousands of computers around the world; or > > 2) it's an Easter egg and coding challenge. > > > My money is on number 1. > > > > > -- > Steven D'Aprano > "Ever since I learned about confirmation bias, I've been seeing > it everywhere." -- Jon Ronson > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
SCons 3.0.2 Release
A new SCons release, 3.0.2, is now available on the SCons download page: https://scons.org/pages/download.html Here is a summary of the changes since 3.0.1: NEW FUNCTIONALITY - Properly support versioned shared libraries for MacOS. We've also introduced two new env variables APPLELINK_CURRENT_VERSION and APPLELINK_COMPATIBILITY_VERSION which will specify what is passed to the linkers -current_version and -compatibility_version flags. If not specified they will be derived from SHLIBVERSION as such: - APPLELINK_CURRENT_VERSION = SHLIBVERSION - APPLELINK_COMPATIBILITY_VERSION = all but the last digit in SHLIBVERSION with .0 appended. Note that the values of the above will be validated. Valid format for either APPLELINK variable is X[.Y[.Z]] where 0 <= X <= 65535, 0 <= Y <= 255, 0 <= Z <= 255. - Add flag must_exist to SConscript() call to fail on missing script. Not failing on missing script is now considered deprecated, and the first instance will print a deprecation message. - Add xz compression format to packaging choices. - Add Textfile/Substfile to default environment. (issue #3147) - Added virtualenv support. A new function Virtualenv() determines whether SCons runs in a virtualenv. The search PATH may also be extended to prefer executables from the current virtualenv over the ones provided by base environment. New option --enable-virtualenv provided to import some virtualenv-related variables to SCons and extend every env['ENV']['PATH'] automatically. New option --ignore-virtualenv disables this. Two environment variables, SCONS_ENABLE_VIRTUALENV and SCONS_IGNORE_VIRTUALENV are supported for the same purpose. DEPRECATED FUNCTIONALITY - Going forward calling SConscript on a non-existing SConscript file will issue a warning. Currently it will issue a deprecation notice. CHANGED/ENHANCED EXISTING FUNCTIONALITY - Recognize new java 9, 10, 11 (as 9.0 and 10.0, 11.0) FIXES - Fix issue #2980 with credit to Piotr Bartosik (and William Blevins). This is an issue where using TimeStamp-MD5 Decider and CacheDir can yield incorrect md5's being written into the .sconsign. The difference between Piotr Bartosik's patch and the current code is that the more complicated creation of file to csig map is only done when the count of children for the current node doesn't match the previous count which is loaded from the sconsign. Thanks to Bernard Blackham, William Deegan, Ray Donnelly, Andrew Featherstone, Arda Fu, Philipp Maierhöfer, Matthew Marinets, Fredrik Medley, Daniel Moody, Gary Oberbrunner, Jonathon Reinhart, Zachary Tessler, Paweł Tomulik, Richard West, Mats Wichmann, Bernhard M. Wiedemann, and Hao Wu for their contributions to this release. Contributors are listed alphabetically by their last name. git shortlog --no-merges -ns 3.0.1..HEAD 226 William Deegan 79 Daniel Moody 72 Mats Wichmann 17 Paweł Tomulik 16 Andrew Featherstone 8 grbd 7 maiphi 6 Gary Oberbrunner 6 Daniel 4 Hao Wu 3 Gabriel Russell 2 MatthewMarinets 2 Jonathon Reinhart 2 ArdaFu 1 Bernhard M. Wiedemann 1 Isaac Pascual Monells 1 Fredrik Medley 1 Philipp Maierhoefer 1 Piotr Kasprzyk 1 Ray Donnelly 1 Zachary Tessler 1 cclauss -- https://mail.python.org/mailman/listinfo/python-list
SCons Version 3.0.3 Released
A new SCons release, 3.0.3, is now available on the SCons download page: https://scons.org/pages/download.html Here is a summary of the changes since 3.0.1: NEW FUNCTIONALITY - Properly support versioned shared libraries for MacOS. We've also introduced two new env variables APPLELINK_CURRENT_VERSION and APPLELINK_COMPATIBILITY_VERSION which will specify what is passed to the linkers -current_version and -compatibility_version flags. If not specified they will be derived from SHLIBVERSION as such: - APPLELINK_CURRENT_VERSION = SHLIBVERSION - APPLELINK_COMPATIBILITY_VERSION = all but the last digit in SHLIBVERSION with .0 appended. Note that the values of the above will be validated. Valid format for either APPLELINK variable is X[.Y[.Z]] where 0 <= X <= 65535, 0 <= Y <= 255, 0 <= Z <= 255. - Add flag must_exist to SConscript() call to fail on missing script. Not failing on missing script is now considered deprecated, and the first instance will print a deprecation message. - Add xz compression format to packaging choices. - Add Textfile/Substfile to default environment. (issue #3147) - Added virtualenv support. A new function Virtualenv() determines whether SCons runs in a virtualenv. The search PATH may also be extended to prefer executables from the current virtualenv over the ones provided by base environment. New option --enable-virtualenv provided to import some virtualenv-related variables to SCons and extend every env['ENV']['PATH'] automatically. New option --ignore-virtualenv disables this. Two environment variables, SCONS_ENABLE_VIRTUALENV and SCONS_IGNORE_VIRTUALENV are supported for the same purpose. DEPRECATED FUNCTIONALITY - Going forward calling SConscript on a non-existing SConscript file will issue a warning. Currently it will issue a deprecation notice. CHANGED/ENHANCED EXISTING FUNCTIONALITY - Recognize new java 9, 10, 11 (as 9.0 and 10.0, 11.0) DOCUMENTATION - Update some doc examples for Py3: map() now returns an iterable instead of a list. FIXES - Fix issue #2980 with credit to Piotr Bartosik (and William Blevins). This is an issue where using TimeStamp-MD5 Decider and CacheDir can yield incorrect md5's being written into the .sconsign. The difference between Piotr Bartosik's patch and the current code is that the more complicated creation of file to csig map is only done when the count of children for the current node doesn't match the previous count which is loaded from the sconsign. Thanks to Bernard Blackham, William Deegan, Ray Donnelly, Andrew Featherstone, Arda Fu, Philipp Maierhöfer, Matthew Marinets, Fredrik Medley, Daniel Moody, Gary Oberbrunner, Jonathon Reinhart, Zachary Tessler, Paweł Tomulik, Richard West, Mats Wichmann, Bernhard M. Wiedemann, and Hao Wu for their contributions to this release. Contributors are listed alphabetically by their last name. git shortlog --no-merges -ns 3.0.1..HEAD 254 William Deegan 79 Daniel Moody 73 Mats Wichmann 17 Paweł Tomulik 16 Andrew Featherstone 8 grbd 7 maiphi 6 Gary Oberbrunner 6 Daniel 4 Hao Wu 3 Gabriel Russell 2 MatthewMarinets 2 Jonathon Reinhart 2 ArdaFu 1 Bernhard M. Wiedemann 1 Isaac Pascual Monells 1 Fredrik Medley 1 Philipp Maierhoefer 1 Piotr Kasprzyk 1 Ray Donnelly 1 Zachary Tessler 1 cclauss -- https://mail.python.org/mailman/listinfo/python-list
SCons 3.0.4 Release
A new SCons release, 3.0.4, is now available on the SCons download page: http://www.scons.org/download.php Or via pypi: pip install scons Here is a summary of the changes since 3.0.3: NEW FUNCTIONALITY - Added TEMPFILESUFFIX to allow user to specify suffix for tempfiles used for long command lines - Initial support for ARM architectures with Microsoft Visual Studio 2017. You must set TARGET_ARCH to arm or arm64 to enable. FIXES - Fixed issue detecting installs of Microsoft Visual Studio 2017 as well as Microsoft build tools 2017. git shortlog --no-merges -ns 3.0.3..HEAD 17 Daniel 10 Mats Wichmann 4 Daniel Moody 4 William Deegan 3 anatoly techtonik 1 Tobias Herzog -- https://mail.python.org/mailman/listinfo/python-list
SCons 3.0.5 Released
A new SCons release, 3.0.5, is now available on the SCons download page:
https://scons.org/pages/download.html
And via pypi:
pip install scons
SCons is a tool for building software (and other files). SCons is
implemented in Python, and its "configuration files" are actually Python
scripts, allowing you to use the full power of a real scripting language
to solve build problems. You do not, however, need to know Python to
use SCons effectively.
Here is a summary of the changes since 3.0.4:
CHANGED/ENHANCED EXISTING FUNCTIONALITY
- Change the default for AppendENVPath to delete_existing=0, so path
order will not be changed, unless explicitly set (Issue #3276)
- Add lex construction variable LEXUNISTD for turning off unix headers on
windows
- Update lex tool to use win_flex on windows if available
- Add the textfile tool to the default tool list
FIXES
- Fix Issue #3283 - Handle using --config=force in combination with
Decider('MD5-timestamp').
3.0.2 in fix for issue #2980 added that deciders can throw
DeciderNeedsNode exception.
The Configure logic directly calls the decider when using
--config=force but wasn't handling
that exception. This would yield minimally configure tests using
TryLink() not running and
leaving TypeError Nonetype exception in config.log
- Fix Issue #3303 - Handle --config=force overwriting the Environment
passed into Configure()'s
Decider and not clearing it when the configure context is completed.
- Add default paths for yacc tool on windows to include cygwin, mingw,
and chocolatey
- Fix issue #2799 - Fix mingw tool to respect SHCCCOMSTR, SHLINKCOMSTR
and LDMODULECOMSTR
- Fix Issue #3329 - Add support for MS SDK V10.0A (which is commonly
installed with VS2017)
- Fix Issue # - Add support for finding vswhere under 32 bit windows
installs.
- Update the MSVC tool to include the nologo flag by default in RCFLAGS
- Fixed bug which threw error when running SCons on windows system with
no MSVC installed.
IMPROVEMENTS
- Do not store build host+user name if reproducible builds are wanted
git shortlog --no-merges -ns 3.0.4..HEAD
34 William Deegan
33 Mats Wichmann
18 Daniel
4 Daniel Moody
3 Bernhard M. Wiedemann
2 Maciej Kumorek
--
https://mail.python.org/mailman/listinfo/python-list
Re: pip vs python -m pip?
you must be picking up pip from a different python installl (or virtualenv) than you are picking up python. Check your %PATH% On Fri, Jun 21, 2019 at 6:29 AM Malcolm Greene wrote: > 64-bit Python 3.6.8 running on Windows with a virtual environment > activated. > > "pip -v" reports 19.0.3 > "python -m pip" reports 19.1.1 > > Is this behavior by design or a bug? > > My takeaway is that its better to run "python -m pip ..." vs "pip ..." > when running pip related tasks. > > Thoughts? > > Malcolm > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
SCons 3.1.0 Released
A new SCons checkpoint release, 3.1.0, is now available
on the SCons download page:
https://scons.org/pages/download.html
SCons is an Open Source software construction tool—that is, a
next-generation build tool. Think of SCons as an improved, cross-platform
substitute for the classic Make utility with integrated functionality
similar to autoconf/automake and compiler caches such as ccache. In short,
SCons is an easier, more reliable and faster way to build software.
Here is a summary of the changes since 3.0.5:
NEW FUNCTIONALITY
- Added variable TEMPFILEARGJOIN to specify how to join arguments
written
to temp files used when command lines exceed MAXLINELENGTH when the
command uses $TEMPFILE{...}
- Support for MSVC 2019
- Upgraded and improved Visual Studio solution/project generation code
using the MSVSProject builder.
- Added support for Visual Studio 2017 and 2019.
- Added support for the following per-variant parameters to the
builder:
- cpppaths: Provides per-variant include paths.
- cppdefines: Provides per-variant preprocessor definitions.
CHANGED/ENHANCED EXISTING FUNCTIONALITY
- Fix performance degradation for MD5-timestamp decider. NOTE: This
changes the Decider() function arguments.
From:
def my_decider(dependency, target, prev_ni):
To:
def my_decider(dependency, target, prev_ni, repo_node):
Where repo_node is the repository (or other) node to use to check if
the node is out of date instead of dependency.
- Enhanced --debug=explain output. Now the separate components of the
dependency list are split up
as follows:
scons: rebuilding `file3' because:
the dependency order changed:
->Sources
Old:xxx New:zzz
Old:yyy New:yyy
Old:zzz New:xxx
->Depends
->Implicit
Old:/usr/bin/python New:/usr/bin/python
- Changed: Pseudo-builders now inherit OverrideEnvironments. For
example when calling a pseudo-builder from another
pseudo-builder the override variables passed to the first
pseudo-builder call had to be explicitly passed on to the
internal pseudo-builder call. Now the second pseudo-builder call
will automatically inherit these override values.
FIXES
- Fix Issue #3350 - SCons Exception EnvironmentError is conflicting
with Python's EnvironmentError.
- Fix spurious rebuilds on second build for cases where builder has > 1
target and the source file
is generated. This was causing the > 1th target to not have it's
implicit list cleared when the source
file was actually built, leaving an implicit list similar to follows
for 2nd and higher target
['/usr/bin/python', 'xxx', 'yyy', 'zzz']
This was getting persisted to SConsign and on rebuild it would be
corrected to be similar to this
['zzz', 'yyy', 'xxx', '/usr/bin/python']
Which would trigger a rebuild because the order changed.
The fix involved added logic to mark all shared targets as peers and
then ensure they're implicit
list is all cleared together.
- Fix Issue #3349 - SCons Exception EnvironmentError is conflicting
with Python's EnvironmentError.
Renamed to SConsEnvironmentError
- Fix Issue #3350 - mslink failing when too many objects. This is
resolved by adding TEMPFILEARGJOIN variable
which specifies what character to join all the argements output into
the tempfile. The default remains a space
when mslink, msvc, or mslib tools are loaded they change the
TEMPFILEARGJOIN to be a line separator (\r\n on win32)
- Additional fix to issue #3135 - Also handle 'pure' and 'elemental'
type bound procedures
- Fix handling of Visual Studio Compilers to properly reject any
unknown HOST_PLATFORM or TARGET_PLATFORM
- Enable LaTeX scanner to find more than one include per line
under which they would be observed), or major code cleanups
git shortlog --no-merges -ns 3.0.5..HEAD
64 William Deegan
56 Mats Wichmann
10 Adam Gross
4 Mathew Robinson
4 Peter Diener
3 Lukas Schrangl
1 Daniel Holth
1 bdbaddog
--
https://mail.python.org/mailman/listinfo/python-list
SCons 3.1.1 Released
SCons - a software construction tool
What is SCons?
SCons is an Open Source software construction tool—that is, a
next-generation build tool. Think of SCons as an improved, cross-platform
substitute for the classic Make utility with integrated functionality
similar to autoconf/automake and compiler caches such as ccache. In short,
SCons is an easier, more reliable and faster way to build software.
Change Log
RELEASE 3.1.1 - Mon, 07 Aug 2019 20:09:12 -0500
From William Deegan:
- Remove obsoleted references to DeciderNeedsNode which could cause
crash when using --debug=explain
From Jason Kenny
- Add Fix and test for crash in 3.1.0 when using
Decider('MD5-timestamp') and --debug=explain
From Ben Reed:
- Added -fmerge-all-constants to flags that get included in both
CCFLAGS and LINKFLAGS.
From Mathew Robinson:
- Fix issue #3415 - Update remaining usages of EnvironmentError to
SConsEnvironmentError
this patch fixes issues introduced in 3.1.0 where any of the
following would cause SCons to error and exit:
- CacheDir not write-able
- JSON encoding errors for CacheDir config
- JSON decoding errors for CacheDir config
--
https://mail.python.org/mailman/listinfo/python-list
Re: Would you be interested in this Python open source project?
You might just consider working with the BuildBot project to add support for lighter weight build workers. Re-Re-Re-inventing the wheel is almost always wasted effort. On Tue, Oct 8, 2019 at 8:33 AM Rhodri James wrote: > On 08/10/2019 11:22, Simon Connah wrote: > > I'm posting this message as a way to gauge interest in the project and > > to see if it is worth moving forward with. There are probably hundreds > > of CI/CD tools out there and many more general devops tools but what I > > want to build is a CI/CD tool that ONLY supports Python 3.6 or greater > > and only runs on one Linux distribution (my preference is Ubuntu). This > > way configuration would be much more simple than the vast majority of > > devops tools which try to support every programming language that is > > popular (or so it seems) on many different Linux distributions and even > > Windows and macOS. > > > > My theory is that if you limit the devops tool to a very limited > > subsection of the available options the system will be easier to > > configure for users, more stable, easier to patch bugs in and generally > > just be a better all around things for Python developers. > > > > I'd love to hear some feedback on the idea. > > > > I think your reasoning is sound. I probably wouldn't make a lot of use > of it, but I live in Embedded Systems land where it's notoriously hard > to do CI off the target silicon. Other people living in more tractable > problem spaces will probably be more enthusiastic. > > -- > Rhodri James *-* Kynesim Ltd > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Using Makefiles in Python projects
You could use SCons (native python... ) On Mon, Nov 11, 2019 at 2:04 PM Grant Edwards wrote: > On 2019-11-11, Rhodri James wrote: > >> I'm sure it's possible to write Makefiles that work with both GNU make > >> and NMake, but I imagine it's a rather limiting and thankless > enterprise. > >> > >> Is that something you actually do? (Maybe it's great, I really wouldn't > >> know. Do tell!) > > > > Trying to work cross-platform with NMake/GNU make is every bit as horrid > > as you're imagining when you start getting clever, and I haven't tried > > doing it for years. > > That's my experience as well. > > > Generally when I'm working on both Windows and Linux, Cygwin is > > involved anyway so I just use GNU make and be done with it. > > And that's also what I usually do. I've been tempted to try msys > make/bash instead of Cygwin, but that's probably not going to happen > until something stops working under Cygwin or I run out of more > entertaining projects before spring. > > -- > Grant Edwards grant.b.edwardsYow! I want another > at RE-WRITE on my CEASAR > gmail.comSALAD!! > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
SCons 3.1.2 Released
A new SCons checkpoint release, 3.1.2, is now available
on the SCons download page:
https://scons.org/pages/download.html
Here is a summary of the changes since 3.1.1:
NOTE: The 4.0.0 Release of SCons will drop Python 2.7 Support
NEW FUNCTIONALITY
- Added debug option "action_timestamps" which outputs to stdout the
absolute start and end time for each target.
REMOVED FUNCTIONALITY
- Turn previously deprecated debug options into failures:
--debug=tree, --debug=dtree, --debug=stree, --debug=nomemoizer.
- Remove deprecated SourceSignatures, TargetSignatures
- Remove deprecated Builder keywords: overrides and scanner
- Remove deprecated env.Copy
- Remove deprecated BuildDir plus SConscript keyword build_dir
CHANGED/ENHANCED EXISTING FUNCTIONALITY
- Update Command() function to accept target_scanner, source_factory,
and target_factory arguments.
This makes Command act more like a one-off builder.
- Added support for "-imacros" to ParseFlags
- EXPERIMENTAL NEW FEATURE: Enable caching MSVC configuration
If SCONS_CACHE_MSVC_CONFIG shell environment variable is set,
SCons will cache the results of past calls to vcvarsall.bat to
a file; integrates with existing memoizing of such vars.
On vs2019 saves 5+ seconds per SCons invocation, which really
helps test suite runs.
FIXES
- Fix suncxx tool (Oracle Studio compiler) when using Python 3.
Previously would throw an exception.
Resolved by properly handling tool version string output as unicode.
- Resolved a race condition in multithreaded Windows builds with Python
2
in the case where a child process is spawned while a Python action
has a
file open. Original author: Ryan Beasley.
- Fix CheckFunc detection code for Visual 2019. Some functions
(e.g. memmove) were incorrectly recognized as not available.
- Fix stacktrace when using SCons with Python 3.5+ and SunOS/Solaris
related tools.
- Latex: Avoid crash with UnicodeDecodeError on Python 3 when a Latex
log file in
non-UTF-8 encoding (e.g. containing umlauts in Latin-1 encoding when
the fontenc package is included with \usepackage[T1]{fontenc}) is
read.
- CmdStringHolder fix from issue #3428
IMPROVEMENTS
- Improved threading performance by ensuring NodeInfo is shared
across threads. Results in ~13% improvement for parallel builds
(-j# > 1) with many shared nodes.
- Improve performance of Entry.disambiguate() by making check for
most common case first, preventing unnecessary IO.
- Improved DAG walk performance by reducing unnecessary work when
there are no un-visited children.
PACKAGING
- N/A
DOCUMENTATION
- N/A
DEVELOPMENT
- N/A
Thanks to the following developers for their contributions to this release.
git shortlog --no-merges -ns 3.1.1..HEAD
59 Mats Wichmann
21 William Deegan
8 Edoardo Bezzeccheri
5 Adam Gross
5 maiphi
4 Ivan Kravets
4 Mathew Robinson
2 Jakub Kulík
2 Jacek Kuczera
2 Rob Boehne
2 Jason Kenny
2 Tim Gates
1 Jakub Kulik
1 Theogen Ratkin
1 jw0k
--
https://mail.python.org/mailman/listinfo/python-list
Re: [Scons-dev] SCons 3.1.2 Released
Glad that helped! Big thanks to Mats Wichmann for that one! On Sat, Dec 21, 2019 at 10:41 AM Eric Fahlgren wrote: > On Mon, Dec 16, 2019 at 7:02 PM Bill Deegan > wrote: > >> - EXPERIMENTAL NEW FEATURE: Enable caching MSVC configuration >> If SCONS_CACHE_MSVC_CONFIG shell environment variable is set, >> SCons will cache the results of past calls to vcvarsall.bat to >> a file; integrates with existing memoizing of such vars. >> On vs2019 saves 5+ seconds per SCons invocation, which really >> helps test suite runs. >> > > Thanks a bunch for this one! Our bare, no-target 'scons' invocation is > down to about 0.8 seconds now, and we can do a single DLL build in ~2.5 s, > which makes things very snappy indeed. > ___ > Scons-dev mailing list > scons-...@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > -- https://mail.python.org/mailman/listinfo/python-list
SCons 4.0.1 Released
A new SCons release, 4.0.1, is now available on the SCons download page: https://scons.org/pages/download.html Here is a summary of the changes since 4.0.1: NEW FUNCTIONALITY - Added Environment() variable TEMPFILEDIR which allows setting the directory which temp files createdby TEMPFILEMUNGE are created in. DEPRECATED FUNCTIONALITY - N/A CHANGED/ENHANCED EXISTING FUNCTIONALITY - N/A FIXES - Fix fortran tools to set SHFORTRAN variables to $FORTRAN, similarly SHF77, SHF90, SHF95, SHF03 and SHF08 will default to the variables $F77, $F90, $F95, $F03 and $F08 respectively. If you were depending on changing the value of FORTRAN (or $F[0-9][0-9]) having no effect on the value of SHFORTRAN, this change will break that. The values of FORTRAN, F77, F90, F95, F03, F08 and SHFORTRAN, SHF77 (etc.) now are not overridden in generate if alredy set by the user. - Fix subprocess execution of 'lslpp' on AIX to produce text standard i/o. - Re-do the fix for suncxx tool (Oracle Studio compiler) now that only Python 3 is supported, to avoid decoding errors. IMPROVEMENTS - N/A PACKAGING - N/A DOCUMENTATION - N/A DEVELOPMENT - N/A Thanks to the following contributors listed below for their contributions to this release. git shortlog --no-merges -ns 4.0.0..HEAD 12 William Deegan 2 Rob Boehne 1 Clemens Tolboom -- https://mail.python.org/mailman/listinfo/python-list
Dictionary order (Is it consistent up to py3.3 unless using -R or PYTHONHASHSEED is set)
Greetings, As a follow up to a discussion on IRC #python channel today. Assuming the same order of insertions of the same items to a dictionary would the iteration of a dictionary be the same (not as the order of insertion, just from run to run) for Python 2.7 up to python 3.3? And again at Python 3.6? (Also for py 3.3 through 3.5.x if PYTHONHASHSEED=0) With python 3.6 having the added benefit of guaranteeing insertion order is maintained? I was pretty certain this was the case from seeing "Modern Dictionaries by Raymond Hettinger" talk at SF Python meetup. https://www.youtube.com/watch?v=p33CVV29OG8 Thanks, Bill -- https://mail.python.org/mailman/listinfo/python-list
Question about propagating universal_newlines through subprocess.Popen to io.TextIOWrapper
Greetings, I was surprised to see that if I set encoding in my call to subprocess.Popen() as follows: p = Popen(cmd, stdin=stdin, stdout=subprocess.PIPE, stderr=stderr_value, env=os.environ, universal_newlines=False, #universal_newlines, encoding='utf-8') That universal_newlines value is discarded due to: text_mode = encoding or errors or universal_newlines ... if text_mode: self.stdout = io.TextIOWrapper(self.stdout, encoding=encoding, errors=errors) There doesn't seem to be a way to set encoding without forcing univeral_newlines. This seems like a bug? -Bill -- https://mail.python.org/mailman/listinfo/python-list
Re: Question about propagating universal_newlines through subprocess.Popen to io.TextIOWrapper
On Mon, Jun 26, 2017 at 12:44 PM, eryk sun wrote: > On Mon, Jun 26, 2017 at 5:23 PM, Bill Deegan > wrote: > > > > That universal_newlines value is discarded due to: > > > > text_mode = encoding or errors or universal_newlines > > > > ... > > > > if text_mode: > > self.stdout = io.TextIOWrapper(self.stdout, > > encoding=encoding, errors=errors) > > > > There doesn't seem to be a way to set encoding without forcing > > univeral_newlines. > > > > This seems like a bug? > > The behavior is documented: > > If encoding or errors are specified, or universal_newlines is true, > the file objects stdin, stdout and stderr will be opened in text > mode using the encoding and errors specified in the call or the > defaults for io.TextIOWrapper. > > For stdin, line ending characters '\n' in the input will be > converted to the default line separator os.linesep. For stdout and > stderr, all line endings in the output will be converted to '\n'. > For more information see the documentation of the io.TextIOWrapper > class when the newline argument to its constructor is None. > > Prior to 3.6, the way to get text streams was to enable > universal_newlines. Maybe for 3.7 the default can change to None, with > the addition of the following code: > > if universal_newlines is None or universal_newlines: > newline = None > else: > newline = '' > > if text_mode: > self.stdin = io.TextIOWrapper(self.stdin, write_through=True, > line_buffering=(bufsize == 1), > encoding=encoding, errors=errors, newline=newline) > Ideally (for my use case) it would be something which propagated universal_newlines to io.TextIOWrapper().. rather than discards it. In my case I want the stdout to be encoded utf-8, but I do not want \r's changed to \n's as my test system is capturing the output of a progress indicator which uses \r to return to beginning of line and overwrite the previous output. -Bill -- https://mail.python.org/mailman/listinfo/python-list
Re: Question about propagating universal_newlines through subprocess.Popen to io.TextIOWrapper
On Mon, Jun 26, 2017 at 2:22 PM, eryk sun wrote: > On Mon, Jun 26, 2017 at 8:59 PM, Bill Deegan > wrote: > > > > Ideally (for my use case) it would be something which propagated > > universal_newlines to io.TextIOWrapper().. rather than discards it. > > In my case I want the stdout to be encoded utf-8, but I do not want \r's > > changed to \n's as my test system is capturing the output of a progress > > indicator which uses \r to return to beginning of line and overwrite the > > previous output. > > An enhancement issue can be created for 3.7, but this is new behavior > that certainly won't be backported to 3.6. For now you'll have to do > it yourself. Leave out the encoding argument, and manually wrap > p.stdout with an io.TextIOWrapper that sets the newline argument to an > empty string. > O.k. I'll file an enhancement. Seems like propagating the values would be better functionality. Thanks! -Bill -- https://mail.python.org/mailman/listinfo/python-list
Re: Windows: python3.exe missing
py -3.5 py -3.6 works. Don't know about py -3.6.0 py -3.6.1 On Fri, Jul 7, 2017 at 11:25 PM, Terry Reedy wrote: > On 7/7/2017 5:45 PM, Andrew Pennebaker wrote: > >> Could the Windows installer for Python 3 provide a "python3" command, >> such as a python3.bat or python3.exe file, to help with scripts that rely >> on the interpreter being called "python3"? >> >> The py launcher is somewhat helpful, but a proper python3 runnable is >> preferable. >> > > Not when one has multiple python 3 installations. > > > -- > Terry Jan Reedy > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
SCons 3.0.0.alpha.20170821 is available for your testing
All,
You can install via: (PLEASE ONLY DO IN A VIRTUALENV AS THIS IS PRERELEASE)
pip install --index-url https://test.pypi.org/simple/
scons==3.0.0.alpha.20170821
This version supports: Python 2.7.x, 3.5.x, 3.6.x
NOTE:
1. You must rm your .sconsign file if you switch python versions between 2
and 3.
2. It is likely you will see a large number of rebuilds due to some changes
with signature generation for python action functions.
Please report any issues you find to the scons users mailing list.
Here's the list of changes:
RELEASE 3.0.0.alpha.20170821 - Mon, 21 Aug 2017 16:15:02 -0700
NOTE: This is a major release. You should expect that some targets
may rebuild when upgrading.
Significant changes in some python action signatures. Also switching
between PY 2 and PY 3.5, 3.6
may cause rebuilds. In no case should rebuilds not happen.
From William Blevins:
- Updated D language scanner support to latest: 2.071.1. (PR #1924)
https://dlang.org/spec/module.html accessed 11 August 2016
- Enhancements:
- Added support for selective imports: "import A : B, C;" -> A
- Added support for renamed imports. "import B = A;" -> A
- Supports valid combinations: "import A, B, CCC = C, DDD = D
: EEE = FFF;" -> A, B, C, D
- Notes:
- May find new (previously missed) Dlang dependencies.
- May cause rebuild after upgrade due to dependency changes.
- Updated Fortran-related tests to pass under GCC 5/6.
- Fixed SCons.Tool.Packaging.rpm.package source nondeterminism
across builds.
From William Deegan:
- Removed deprecated tools CVS, Perforce, BitKeeper, RCS, SCCS, Subversion.
- Removed deprecated module SCons.Sig
- Added prioritized list of xsltproc tools to docbook. The order
will now be as
follows: xsltproc, saxon, saxon-xslt, xalan (with first being
highest priority, first
tool found is used)
- Fixed MSVSProject example code
(http://scons.tigris.org/issues/show_bug.cgi?id=2979)
- Defined MS SDK 10.0 and Changed VS 2015 to use SDK 10.0
- Changes to Action Function and Action Class signiture creation.
NOTE: This will cause rebuilds
for many builds when upgrading to SCons 3.0
- Fixed Bug #3027 - "Cross Compiling issue: cannot override ranlib"
- Fixed Bug #3020 - "Download link in user guide wrong. python
setup.py install --version-lib broken"
- Fixed Bug #2486 - Added SetOption('silent',True) - Previously
this value was not allowed to be set.
- Fixed Bug #3040 - Non-unicode character in CHANGES.txt
- Fixed Bug #2622 - AlwaysBuild + MSVC regression.
- Fixed Bug #3025 - (Credit to Florian : User flow86 on tigris) -
Fix typo JAVACLASSSUFIX should have been
JAVACLASSSUFFIX
From Ibrahim Esmat:
- Added the capability to build Windows Store Compatible libraries
that can be used
with Universal Windows Platform (UWP) Apps and published to the store
From Daniel Holth:
- Add basic support for PyPy (by deleting __slots__ from Node with a
metaclass on PyPy); wrap most-used open() calls in 'with' statements to
avoid too many open files.
- Add __main__.py for `python -m SCons` in case it is on PYTHONPATH.
- Always use highest available pickle protocol for efficiency.
- Remove unused command line fallback for the zip tool.
From Gaurav Juvekar:
- Fix issue #2832: Expand construction variables in 'chdir'
argument of builders. (PR #463)
- Fix issue #2910: Make --tree=all handle Unicode. (PR #427)
- Fix issue #2788: Fix typo in documentation example for sconf. (PR #388)
From Alexey Klimkin:
- Use memoization to optimize PATH evaluation across all dependencies per
node. (PR #345)
- Use set() where it is applicable (PR #344)
From M. Limber:
- Fixed msvs.py for Visual Studio Express editions that would report
"Error : ValueError: invalid literal for float(): 10.0Exp".
From Rick Lupton:
- Update LaTeX scanner to understand \import and related commands
From Steve Robinson:
- Add support for Visual Studio 2017. This support requires
vswhere.exe a helper
tool installed with newer installs of 2017. SCons expects it to
be located at
"C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe"
It can be downloaded separately at
https://github.com/Microsoft/vswhere
From Paweł Tomulik:
- Fixed the issue with LDMODULEVERSIONFLAGS reported by Tim Jennes
(https://pairlist4.pair.net/pipermail/scons-users/2016-May/004893.html).
An error was causing "-Wl,Bsymbolic" being added to linker's command-line
even when there was no specified value in LDMODULEVERSION and thus no
need for the flags to be specified.
- Added LoadableModule to the list of global functions (DefaultEnvironment
builders).
From Manish Vachharajani:
- Update debian rules, compat, and control to not use features
deprecated or obsolete in lat
Re: SCons 3.0.0.alpha.20170821 is available for your testing
What is SCons? SCons is an Open Source software construction tool—that is, a next-generation build tool. Think of SCons as an improved, cross-platform substitute for the classic Make utility with integrated functionality similar to autoconf/automake and compiler caches such as ccache. In short, SCons is an easier, more reliable and faster way to build software. see http://scons.org for more info. -Bill SCons Project Co-Manager On Wed, Aug 23, 2017 at 4:26 AM, Steve D'Aprano wrote: > On Tue, 22 Aug 2017 09:51 am, Bill Deegan wrote: > > > All, > > > > You can install via: (PLEASE ONLY DO IN A VIRTUALENV AS THIS IS > PRERELEASE) > > > > pip install --index-url https://test.pypi.org/simple/ > > scons==3.0.0.alpha.20170821 > > > What is scons and why should we be interested in it? > > > Thanks, > > > > -- > Steve > “Cheer up,” they said, “things could be worse.” So I cheered up, and sure > enough, things got worse. > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Help needed - - running into issues with python and its tools
Your approach is wrong. You don't build python from source using pip. You don't install new versions of python into a venv either. Have you read the following? https://docs.micropython.org/en/latest/esp8266/tutorial/intro.html That seems to have instructions for what you want to do.. -Bill On Mon, Aug 5, 2024 at 1:41 PM o1bigtenor via Python-list < python-list@python.org> wrote: > Matt - if you would rather that you were not included in the address list - > - > please advise. > > On Mon, Aug 5, 2024 at 8:51 AM Mats Wichmann wrote: > > > On 8/5/24 06:48, o1bigtenor via Python-list wrote: > > > On Sun, Aug 4, 2024 at 8:49 AM Mats Wichmann via Python-list < > > > python-list@python.org> wrote: > > > > > >> On 8/3/24 20:03, o1bigtenor via Python-list wrote: > > >> > > >>> My question was, is and will be (and the doc absolutely doesn't cover > > it) > > >>> how do I install a different version in the venv so that python > 3.11.x > > on > > >>> the > > >>> system is not discombobulated by the python 3.12.x in the venv. > > >>> That python 3.12 would let me run the tools needed. > > >>> (Its the how to install the next version of python that I just > haven't > > >> been > > >>> able to find information on - - - and I would be looking for > > information > > >>> on how to install on a *nix.) > > >> > > >> To get a different Python "in" the venv, you use the version you want > in > > >> the construction of the venv. For example: > > >> > > >> > > >> $ python3.13 -m venv new_venv > > >> $ new_venv/bin/python --version > > >> Python 3.13.0b4 > > >> $ source new_venv/bin/activate > > >> > > >> > > > "https://peps.python.org/pep-0668/ PEP 668, which prevents pip from > > > interacting with the OS installed python. This change has been done in > > red > > > hat and other distros too . . . " > > > > > > similarly your first command produces and error code for the same > reason. > > > > > > Sorry - - - not my policy - - - > > > > What? Yes, the *system* pip should have some restrictions, if it's a > > system mainly managed by a package manager. > > > > Setting up a venv is the *expected* approach to such situations, and > > creating one doesn't cause any problems. You end up with a pip in the > > activated venv that's going to install to a different path (the one in > > the venv), and will not be marked as externally managed, as the package > > manager has no control over that path. > > > > That's the whole point. What error are you getting? The venv module is > > not the pip module so restrictions on the system pip have nothing to do > > with it. > > > > set up pyenv > activated a venv > trying to install python3.12 into it > > 1. download of python3.12 (blahblahblahetc).deb will not install > 2. download of python3.12.tar.xz similarly will not install > > (venv2) memyself@devuanbigbox:~$ pip install > /home/memyself/Downloads/Python-3.12.4.tar.xz > Processing ./Downloads/Python-3.12.4.tar.xz > ERROR: file:///home/memyself/Downloads/Python-3.12.4.tar.xz does not appear > to be a Python project: neither 'setup.py' nor 'pyproject.toml' found. > > seems that I need a different version (installable as it were) of > python3.12 > or my approach is all wrong! > > Please advise > > TIA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Help needed - - running into issues with python and its tools
Did Mats suggestion of: python3.13 -m venv new_venv $ new_venv/bin/python --version Python 3.13.0b4 $ source new_venv/bin/activate Not work? That should work on any system, with any system installl python. It's not trying to modify the system installed python in anyway... If not, please paste the error output you're getting. On Mon, Aug 5, 2024 at 3:13 PM Mats Wichmann via Python-list < python-list@python.org> wrote: > On 8/5/24 15:17, o1bigtenor via Python-list wrote: > > >> That's something like > >> > >> pyenv install 3.12.4 > >> > > > > $ pyenv install 3.12.4 > > bash: pyenv: command not found > > > > > pyenv is not a 'global' package > > > > there is a mountain of /root/.pyenv files though > > there is also quite a number of /root/.pyenv/plugins/pyenv-virtualenv/ > > files > > > > when looking in the /root/.pyenv files I can find options for all the > older > > version of python > > but none for anything newer than what is on my system > > > > is there something else to install to achieve this 'version freedom' that > > pyenv promises? > > It has to go somewhere your shell can find it. Mine is a shell > function, but it was set up so many years ago I don't remember details. > It's presumably the pyenv installation instructions... > > > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Help needed - - running into issues with python and its tools
why reply to me instead of to the list? It's generally considered bad form to do so. Do you have any python 3 installed on your system? Or python 2.7? If not, can you install such via system package? -Bill On Mon, Aug 5, 2024 at 6:06 PM o1bigtenor wrote: > > > On Mon, Aug 5, 2024 at 5:28 PM Bill Deegan via Python-list < > python-list@python.org> wrote: > >> Did Mats suggestion of: >> python3.13 -m venv new_venv >> $ new_venv/bin/python --version >> Python 3.13.0b4 >> $ source new_venv/bin/activate >> >> Not work? >> That should work on any system, with any system installl python. >> It's not trying to modify the system installed python in anyway... >> >> If not, please paste the error output you're getting. >> > > # python3.13 -m venv new_venv > -bash: python3.13: command not found > > $ python3.13 -m venv new_venv > bash: python3.13: command not found > > There you have it - - - the first one run as superuser and the second as > usr. > > Regards > > > -- https://mail.python.org/mailman/listinfo/python-list
Re: Help needed - - running into issues with python and its tools
I’m not looking through all the packages you have installed What version of python is installed on your system? On Tue, Aug 6, 2024 at 5:24 AM o1bigtenor wrote: > > > On Mon, Aug 5, 2024 at 10:36 PM Bill Deegan > wrote: > >> why reply to me instead of to the list? >> It's generally considered bad form to do so. >> > > Got it - - - except this list wants only reply all the next one wants only > reply and > keeping straight which is which isn't always happening. I did apologize > and asked > you to advise in the next one whether you even wanted to be included > (which you haven't > responded to). > >> >> >> Do you have any python 3 installed on your system? >> Or python 2.7? >> If not, can you install such via system package? >> > > > # dpkg -l | grep python* > ii 2to3 3.11.2-1 > all 2to3 binary using python3 > ii idle-python3.113.11.2-6+deb12u2 > all IDE for Python (v3.11) using Tkinter > ii ipython3 8.5.0-4 > all Enhanced interactive Python 3 shell > ii libboost-python1.74.0 1.74.0+ds1-21 > amd64Boost.Python Library > ii libpython3-all-dev:amd64 3.11.2-1+b1 > amd64package depending on all supported Python 3 > development packages > ii libpython3-dev:amd64 3.11.2-1+b1 > amd64header files and a static library for Python > (default) > ii libpython3-stdlib:amd643.11.2-1+b1 > amd64interactive high-level object-oriented language > (default python3 version) > rc libpython3.10-minimal:amd643.10.9-1 > amd64Minimal subset of the Python language (version > 3.10) > ii libpython3.11:amd643.11.2-6+deb12u2 > amd64Shared Python runtime library (version 3.11) > ii libpython3.11-dev:amd643.11.2-6+deb12u2 > amd64Header files and a static library for Python > (v3.11) > ii libpython3.11-minimal:amd643.11.2-6+deb12u2 > amd64Minimal subset of the Python language (version > 3.11) > ii libpython3.11-stdlib:amd64 3.11.2-6+deb12u2 > amd64Interactive high-level object-oriented language > (standard library, version 3.11) > ii libpython3.11-testsuite3.11.2-6+deb12u2 > all Testsuite for the Python standard library (v3.11) > ii libpython3.9-minimal:amd64 3.9.13-1 > amd64Minimal subset of the Python language (version > 3.9) > ii libpython3.9-stdlib:amd64 3.9.13-1 > amd64Interactive high-level object-oriented language > (standard library, version 3.9) > ii python-apsw-doc3.40.0.0-2 > all documentation for python-apsw > ii python-apt-common 2.6.0 > all Python interface to libapt-pkg (locales) > ii python-apt-common-devuan 2.5.3devuan2 > all Templates for aptitude > ii python-attr-doc22.2.0-1 > all documentation for the attrs Python library > ii python-babel-localedata2.10.3-1 > all tools for internationalizing Python applications > - locale data files > ii python-cryptography-doc38.0.4-3 > all Python library exposing cryptographic recipes > and primitives (documentation) > ii python-cycler-doc 0.11.0-1 > all composable kwarg iterator (documentation) > ii python-gmpy2-common2.1.2-2 > all common files for python3-gmpy2 > ii python-ipython-doc 8.5.0-4 > all Enhanced interactive Python shell (documentation) > ii python-markdown-doc3.4.1-2 > all text-to-HTML conversion library/tool > (documentation) > ii python-matplotlib-data 3.6.3-1 > all Python based plotting system (data package) > ii python-matplotlib-doc 3.5.2-4 > all Python based plotting system (documentation > package) > ii python-m
