We Keep Coding

Unable to find package 'pythonx86' via nuget

I downloaded the CPython source code from the CPython GitHub repo and ran .\PCBuild\build.bat -p x64 -c Debug in the command line of VScode. Inside .\cpython\PCBuild\ it consists build.bat. As I wanted to make a compiled CPython binary, executing build.bat will create .\PCBuild\amd64\python_d.exe.When that .bat file gets executed it says,
Installing Python via nuget...
Feeds used:
Installing package 'pythonx86' to 'D:\CHETAN\cpython\externals'
and print the error message as :
Unable to find package 'pythonx86'
Can anyone have a fix for this. Any help will be appreciated.

Try to build the source code with the latest Visual Studio.
Visual Studio 2022 Community can work well:
The external folder only contains following packages:
You can also use dumpbin to check python_d.exe dependents.

How to install METIS package in python on windows?

I am currently running a source code in python which uses METIS. I wanted to run it using Jetbrains PyCharm, conda interpreter and these are installed on windows 10. Although I have installed METIS using conda, I could not enable shared libraries and I faced this error:
ModuleNotFoundError: No module named 'metis'
When I tried to run it without conda I faced the following error although I have added the metis.dll location to the environment variables.
RuntimeError: Could not load METIS dll
Could anyone please help me about it?

This question is old, but I ran into the same problem and after going down the rabbit's hole for.. too long... I have an answer that worked for me.
First, you should get the python metis wrapper using pip: pip install metis.
Second, You must install conda-metis, which you can find here. Although pip calls the metis python wrapper metis, it just the metis wrapper and does not have metis itself.
Place the files in conda-metis-master in some file path.
The installation requires some fixes. Make sure you have a recent version of Visual Studios (I used 2017). For me, VS had a problem running the instructions in BUILD-WINDOWS.txt, which landed me on this thread:
Why does MSBuild look in C:\ for Microsoft.Cpp.Default.props instead of c:\Program Files (x86)\MSBuild? ( error MSB4019)
Specifically, the answer For Visual Studio 2017 and 2019 on Windows 10 was what I went with. Run:
set VCTargetPaths=C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets
in command prompt with full permissions to set the environment variable.
Also go to Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ in regedit and change in 4.0 the variable MSBuildOverrideTasksPath and in ToolsVersion\4.0\ the variable MSBuildToolPath to C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin.
For the python metis, we need a .dll, not .lib[1], so we must also look closer at the CMakeLists.txt (see the Linux version of this discussion here). We add on line 19: set(METIS_LIBRARY_TYPE SHARED).
You should follow the BUILD-WINDOWS.txt instructions, but run .\vsgen -G "Visual Studio 15 2017 Win64" inside your conda-metis file path in command prompt with full permissions instead of using Visual Studio 10.
Wait! We need another fix before following the instructions further on using VS to build the the library. Following what was said in:
rint() issue after creating VS Project using CMake
we have to edit the file path_to_your_metis_dir\GKlib\gk_arch.h by removing the line: #define rint(x) ((idx_t)((x)+0.5)). (Or the fix listed on this github exchange.)
Then go to path_to_your_metis_dir\build\windows\.
Open METIS.sln in Visual Studios, go to the top to Build and from the scroll-down go to Build Solution. Afterwards, the .dll file will be in path_to_your_metis_dir\build\windows\libmetis\Release\.
Last, we run in command prompt:
set METIS_DLL=path_to_your_metis_dir\build\windows\libmetis\Release\metis.dll
After this, python metis no longer failed on the step from metis import * for me.
[1] If we could use .lib, then conda install -c conda-forge metis would work to get this file, but setting METIS_DLL to the .lib file leads to a windows error.

After getting the error described by #XiaojianChen , this is how I solved it (VS Studio 2022). Continuing after the above fixes, to generate a .dll file after opening up the VS solution file, go to the Solution Explorer, right click on the metis project file -> properties.
In General Properties, change the configuration type to Dynamic Library (.dll)
Screenshot of General Properties window
Under Advanced Properties, change the Target File Extension from .lib to .dll
Screenshot of Advanced Properties window
Since we only need the metis.dll file, right click the metis project file in the Solution Explorer and click build. The .dll can be found in ..\build\windows\libmetis\Release.

Windows 10 - Using Labellmg for object detection - Installing PyQt

A beginner here.I have been trying to get Labellmg work using the following source on Github:
https://github.com/tzutalin/labelImg
I was confused as to if I could just download the .exe file found in 'Download prebuilt binaries' or if I have to build it from source. So, I went with building it from source anyway:
Here are the steps I followed: (I have python 3.5 and lxml already installed)
Installed Visual Studio 2010 from here:
http://download.cnet.com/Microsoft-Visual-Studio-2010-Ultimate/3000-2383_4-75450998.html
Downloaded SIP source code (version 4.19.5) from here:
https://www.riverbankcomputing.com/software/sip/download
Downloaded PyQt4 source code (version 4.12.1) from here:
https://www.riverbankcomputing.com/software/pyqt/download
Downloaded and Installed Qt
(qt-opensource-windows-x86-vs2010-4.8.6.exe)
Staying in one Command Prompt and in the sip-4.19.5 directory, I entered the following commands:
python configure.py
"C:\Qt\4.8.6\bin\qtvars.bat"
"C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\vcvarsall.bat"
nmake
The first three steps are successful but when I execute the nmake command, I get the following error:
I am probably doing something really silly. Kindly, please help me out! I have been stuck with this problem for more than 8 hours straight now.

vcvarsall.bat not found - python

My OS is windows 8 and python version is 3.4, Microsoft visual studio 11.0 .
While trying to install mod_wsgi I am getting vcvarsall.bat not found. I have changed my environment variables VS100COMNTOOLS value to VS110COMNTOOLS. But still getting same error.
I tried to install SDK for windows8 and .netframework 4.0 but it failed.
In my system I have following .net folder: C:\Windows\Microsoft.NET under this I have following folders : assembly; authman; Framework; Framework64.
I also have Microsoft.Net folder in C:\Program Files (x86)\Microsoft.NET.
I installed Windows kit under same folder.
I tried to resolved the problem using nmake -f ap24py34-win64-VC10.
It's giving the following error:
v1077: "c:\program Files <x86>\Microsoft Visual Studio 11.0\VC\BIN\c1.Exe":return code '0x2' stop.
Please help me to fix this problem
Thanks in advance

According to this page python 3.4 needs Visual C++ 10.0. You actually need it installed. If you read further down the page, you'll find a link to a standalone distro provided by MS. Installing this should fix the problem.

Error: "MSVCP90.dll: No such file or directory" even though Microsoft Visual C++ 2008 Redistributable Package is installed

I'm trying to build a package from source by executing python setup.py py2exe
This is the section of code from setup.py, I suppose would be relevant:
if sys.platform == "win32": # For py2exe.
import matplotlib
sys.path.append("C:\\Program Files\\Microsoft Visual Studio 9.0\\VC\\redist\\x86\\Microsoft.VC90.CRT")
base_path = ""
data_files = [("Microsoft.VC90.CRT", glob.glob(r"C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT\*.*")),
Error it shows:
*** finding dlls needed ***
error: MSVCP90.dll: No such file or directory
But I've installed "Microsoft Visual C++ 2008 Redistributable Package". I'm running 32-bit python on 64-bit Windows 8. I'm trying to build a 32-bit binaries.
Also there is no folder like this: "C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\". This is what my computer contains:
EDIT:
On searching for msvcp90.dll on my C:\ drive I found that they are installed in weird paths like this:

I would recommend ignoring the dependency outright. Add MSVCP90.dll to the list of dll_excludes given as an option to py2exe. Users will have to install the Microsoft Visual C++ 2008 redistributable. An example:
setup(
options = {
"py2exe":{
...
"dll_excludes": ["MSVCP90.dll", "HID.DLL", "w9xpopen.exe"],
...
}
},
console = [{'script': 'program.py'}]
)

(new answer, since the other answer describes an alternate solution)
You can take the files from the WinSxS directory and copy them to the C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT directory (normally created by Visual Studio, which you don't have). Copy them to get the following structure:
+-Microsoft.VC90.CRT
| |
| +-Microsoft.VC90.CRT.manifest
| +-msvcm90.dll
| +-msvcp90.dll
| +-msvcr90.dll
Then, you should be able to run the setup program (still excluding msvcp90.dll, as in the other answer), and it should successfully find the files under Microsoft.VC90.CRT and copy them as data files to your bundle.
See the py2exe tutorial for more information.

I used to have a huge number of problems with complication on Windows, like the issue you're facing as well as installing packages like Cython with pip install cython.
The solution that worked best for me after two weeks of pain was downloading and running the unofficial MinGW GCC binary for Windows provided here. You might want to try giving that a shot and seeing if it helps.
If you do do it, you might want to uninstall MinGW if you have it already. I don't know if that's strictly necessary, but I always did it just in case. I did have it installed side-by-side with Cygwin without any problems.

I think it has something to do with the spaces in the directory. You should try using .rstrip(). For example, put this:
directory='C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT'
directory=directory.rstrip()
You can then use the variable directory like you would have used the actual path.
This should make python able to recognize the directory where it wouldn't be able to decipher it before.