Develop Reference

python code and it's pyInstaller generated executable give different output [duplicate]

I am developing desktop database application. Using rdlc report and reportviewer. Everything was fine in developing process, reportviewer was showing all data smoothly. I deploy app with Inno Setup. But when I install the app, the reportviewer is not showing data. While data is correctly inserted in the tables.

For applications that work incorrectly or fail completely, when installed by Inno Setup to Program Files folder, the first thing to test, is to try to deploy the application manually to the same folder.
If the application fails even after a manual deployment, the most usual problem is that the application requires a user to have write permissions to application folder. As on modern versions of Windows a user typically does not have write permissions to the Program Files folder, the application does not work. So the problem usually has nothing to do with Inno Setup, but it's a problem of the application itself.
To solve the problem:
The best solution is to redesign the application so that it does not require write permissions to its folder. Windows applications should not require write permissions to their folder. That's against Windows guidelines. The application should write data to a user profile folder (C:\Users\username\AppData) or to a common data folder (C:\ProgramData).
A dirty workaround is have the installer grant a user(s) write permissions to the installation folder. Do that only, if you cannot get the application fixed (e.g. it's 3rd party application).
See Inno Setup - How to set permissions of installation folder.
Even more gross workaround is to configure the application to be executed with elevated (Administrator) privileges.
See Inno Setup desktop shortcut (link) which has "Run as administrator" advanced property set
or How to set 'Run as administrator' on a file using Inno Setup.
Another solution is enabling legacy compatibility mode that makes Windows redirect all application write attempts to a virtual store. See also Application installed with Inno Setup writes files to unknown location instead of its installation folder.
There are numerous other possible reasons, why the application might be failing when installed, including:
You omitted some dependency:
DLL library
.NET assembly
.NET Framework
Java Runtime Environment
other runtime
COM/ActiveX object, etc.
The application requires some configuration:
a file
a registry key [including COM/ActiveX object registration]
an environment variable, etc.
The application is not designed to be executed from a folder that has a space in its name (Program Files).
The application gets confused by Windows File virtualization (though it's unlikely). See Application installed with Inno Setup writes files to unknown location instead of its installation folder.

Is is possible to run a pyramid application without installing it as an egg?

I am building an application using the Pyramid web framework and in all of the documentation it assumes that you will be installing your application as an egg using setup.py. While this makes sense for a distributable package, it adds a lot of overhead and unnecessary packaging code for an application that isn't meant to be shared as a library or extension.
Pyramid uses PasteDeploy to read application configuration files (.ini) and requires a section to define which application is to be run:
[app:blog]
use = egg:MyBlog#main
database = mysql://localhost/blogdb
blogname = This Is My Blog!
This tells the app loader to import a library called MyBlog found on the PYTHONPATH and use an entry point named main that has been defined in a setup.py configuration.
Is there any way to directly refer to the application by path and specify the WSGI entry point (similar to how you would run an application directly via:
cd /path/to/MyBlog
gunicorn --bind etc... app:main
There is an additional syntax starting with call: that allows you specify an entry point that hasn't been registered with setuptools:
[app:mythirdapp]
use = call:my.project:myapplication
However, it appears that the loader still expects a package installed on the python path rather than a bare python package/executable.

Is it possible to run a pyramid application without installing it as an egg?
Yes, it is, you can find a lot of examples on https://trypyramid.com/ site. You are not obliged to use ini-style declaration for runnig your WSGI application. For example you can create myapp_wsgi.py file:
from pyramid.paster import get_app, setup_logging
ini_path = 'production.ini'
setup_logging(ini_path)
application = get_app(ini_path, 'main')
And pass it to gunicorn:
gunicorn myapp_wsgi:application
You can find more information on modwsgi and gunicorn. pages.

I actually think the call: method is able to find a package that hasn't been installed using setuptools. This is due to the fact that the python path starts in the current directory, so if you launch your app from the directory containing it, then everything should work as expected.
Problems arise when you want to compose apps using the [composite:] directive. It would be nice if [app:] sections could include a directory = ... parameter that would add that directory to the python path, but I guess this is more of a feature request to raise with the PasteDeploy developers...

Is there a typical mod_wsgi project directory?

I've followed the excellent tutorial https://www.digitalocean.com/community/tutorials/how-to-serve-django-applications-with-apache-and-mod_wsgi-on-centos-7 to install Apache, mod_wsgi, and Django. All such tutorials leave the location of the python virtual environment and Django project up to the developer, but I'm wondering if there is any Best Practice for selecting an appropriate location. For example, the tutorial suggests creating a virtual environment in the user's home directory:
mkdir ~/myproject
cd ~/myproject
virtualenv myprojectenv
and
WSGIDaemonProcess myproject python-path=/home/user/myproject:/home/user/myproject/myprojectenv/lib/python2.7/site-packages
(Python 3.4 wisely discarded virtualenv, replacing it with the automatically-created version-specific pyvenv-3.4.)
Now that Apache successfully displays the Django 1.8 startup page ("Get to work!"), I want to put the project in a location more suitable to a production environment than my home directory. Options include:
1) The Apache ServerRoot /etc/httpd - that was my first thought, except that /etc is (should be?) used just for configuration information, not installed software
2) Leave it in my home directory /home/username/myproject - undesirable because I'd rather not give permission for httpd to read my home directory, and because I'd rather not be able to accidentally mess up the project when logged in as me.
3) Create a project directory in /home, e.g. /home/myproject or /home/web/myproject, without creating a user account for myproject or web. That's my current preferred option, but it seems a bit strange to have directories in /home not owned by a user. All files in the project would be owned by root:apache, with read-only permission for the apache daemon and no permissions for world.
4) Elsewhere, such as /bin, /lib, or /lib64, none of which seem particularly suitable.
5) DocumentRoot /var/www - DEFINITELY NOT!
So are there any best practice conventions for where to set up a production Django project on a Linux server?

By Filesystem Hierarchy Standard the site specific services running on the server should go under /srv.
In your case this could be /srv/django/myproject.

Deploying Flask on Windows in production

I have found quite a few guides for running Flask on Linux/Unix with various technologies (nginx/apache/uWSGI/gunicorn/etc.) but all of them appear to work best on Linux, and only incidentally work on Windows, or not work at all on Windows. Are there any recommended ways to serve Flask apps in production in a Windows environment?

I have done this a few times. It can be done with only moderate hits to performance. You will want to leverage IIS and FastCGI.
Here is a link to a blog post detailing a method: https://medium.com/#bilalbayasut/deploying-python-web-app-flask-in-windows-server-iis-using-fastcgi-6c1873ae0ad8
Here is a link to a SO post detailing the same method: https://stackoverflow.com/a/22107980/8508792
and the contents, just in case the post gets taken down...
High Level Overview
HTTP -> IIS -> ISAPI -> FastCGI -> WSGI (Flask application)
Setup Steps
Step 1: Install Required Binaries
Install Python (2.7 or 3.x -- I used 3.3)
Install pip-Win (I used version 1.6)
Install pywin32 (I used version 218)
Install the IIS FastCGI extension with fcgisetup 1.5
Step 2: Install Optional Binary Packages
I installed pyodbc using the installer .exe from this site. Installing from source (e.g. pip, for installing into a virtual environment) requires a C/C++ compiler.
Step 3: Get a Copy of wfastcgi.py
Choose a version that will work for you, preferably one that supports Python 3.3 (I used David Ebbo's). You may want the "official" version from here.
Install the wfastcgi.py script into C:\Inetpub\wwwroot and make sure the account that will serve your application ("Network Service" by default) has read access to it.
Step 4: Install virtualenv Into the System site-packages
C:\Python33\Scripts\pip.exe install virtualenv
(if you are using Python 3.3 and installed everything in the default location)
Step 5: Install Your Flask Application
You may install the application just about anywhere on the system. You may want to install it under C:\Inetpub. For this tutorial, we'll call the root folder of your application install %APPROOT%. (Don't put quotation marks in the environment variable.)
Make sure that the account that will serve your application ("Network Service" by default) has read access to all of the script files. This command:
cacls "%APPROOT%" /S:"D:PAI(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;0x1200a9;;;NS)(A;OICI;FA;;;SY)"
will give your application directory the following permissions:
BUILTIN\Administrators: Full control of this folder, subfolders, and files
CREATOR OWNER: Full control for subfolders and files only
NT AUTHORITY\NETWORK SERVICE: Read permissions for this folder, subfolders, and files
NT AUTHORITY\SYSTEM: Full control of this folder, subfolders, and files
Add any local configuration necessary (my application uses a local.cnf file that is ignored by the version control system) -- e.g. database URLs.
Make sure your application contains a Web.config file in %APPROOT% -- see the section below for information on the file format.
Step 6: Create a virtualenv For Your Application
C:\Python33\Scripts\virtualenv.exe --system-site-packages "%APPROOT%\env"
(Pick a name other than env if your application already uses that directory.)
Step 7: Install The Packages Required By Your Application to the virtualenv
cd "%APPROOT%"
env\Scripts\activate
pip install -r Packages
(My project keeps the requirements spec in a file named Packages.)
Step 8: Create a Web Site Or Virtual Directory For Your Application
Use inetmgr.msc (Start -> Run…, then enter inetmgr in the edit box and press ENTER) to launch Internet Information Services (IIS) Manager. Make sure to set the local path for the node (Web Site or Virtual Directory) you create to the root folder of your Flask application. wfastcgi.py uses the local path to identify the Flask application to handle the requests.
Give both Read and Script (Run Scripts) permissions for the node.
Step 9: Configure fcgiext.ini
This file is located in the same directory as the fcgiext.dll installed in Step 1 (by default, %SYSTEMROOT%\system32\inetsrv).
In configuring this file, you need several parameters:
{site id}: the numeric Site ID you can find in the detail (right-hand) pane of Internet Information Services (IIS) Manager when “Web Sites” is selected from the tree on the left side of the window.
{application name}: the name of the section within fcgiext.ini that provides the parameters for the FastCGI (ISAPI) handler. You choose this value -- select something that represents your application.
{path to app}: for a Virtual Directory, the URL path within the Web Site to the Virtual Directory to be handled.
{approot}: the path to the root directory of your application.
Use those parameters to:
Map the FastCGI requests to a handling section:
For a whole Web Site, add *:{site id}={application name} to the [Types] section.
For a Virtual Directory, add *:/lm/w3svc/{site id}/root/{path to app}={application name} to the [Types] section.
Add a handling section ([{application name}]) with parameters for this application (full reference):
ExePath={approot}\env\python.exe
Arguments=C:\Inetpub\wwwroot\wfastcgi.py (or wherever the wfastcgi.py adapter script is installed)
EnvironmentVars=ENV_VAR1:value,ENV_VAR2:value,etc. (see the full reference for quoting rules). This is a good place to set your WSGI_LOG environment variable -- make sure the account serving the site (“Network Service” by default) has write permissions for the file and (if the file doesn’t exist) permission to add a file to the containing directory.
Step 10: Configure FastCGI Handling for the Target URLs
Using Internet Information Services (IIS) Manager, select “Properties...” from the context (right-click) menu of the node (Web Site or Virtual Directory) to be served by your Flask application and:
In the “Home Directory” tab (Web Site) or “Virtual Directory” tab (Virtual Directory), click the “Configuration..." button.
In the “Wildcard application maps” section, use the “Insert..." button to add a wildcard mapping:
The executable is the FastCGI extension DLL installed in Step 1. Its default location is %SYSTEMROOT%\system32\inetsrv\fcgiext.dll.
Make sure “Verify that file exists” is unchecked. Flask applications do their own routing that doesn’t necessarily have anything to do with the files on the disk.
Web.config
This file is (in this setup) read by wfastcgi.py, not by IIS.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<applicationSettings>
<add key=“PYTHONPATH” value=“”/>
<add key=“WSGI_HANDLER” value=“module.application”/>
</applicationSettings>
</configuration>
<add> elements add environment variables (os.environ in Python).
WSGI_HANDLER must be specified -- it tells wfastcgi.py how to locate the WSGI application object. If the value ends in "()", wfastcgi.py will call the named object, expecting it to return a WSGI application object.
PYTHONPATH is handled specially -- wfastcgi.py performs (environment) variable expansion (using the Windows standard %VAR% notation) on the value of PYTHONPATH, then splits the result at semicolons and appends the entries to sys.path before invoking the WSGI application. Because wfastcgi.py changes the current directory to the path specified as the local path of the Web Site or Virtual Directory before importing the module containing the WSGI application object, including an empty string in the PYTHONPATH will cause the search to include your Flask application directory as a starting point. You can also set PYTHONPATH in fcgiext.ini (in which case it is included in sys.path by the interpreter and then again by wfastcgi.py).
WSGI_RESTART_FILE_REGEX gives a Python regular expression used to filter file-change notifications for paths that should trigger FastCGI handler process restarts. Set this to trigger when source files or configuration files change. I use (?i).*\.(py|cnf|config)$.
WSGI_LOG may be set here, but I think it is better set in fcgiext.ini.
For IIS 7
Some things with FastCGI changed dramatically with IIS 7. Beginning with this version, FastCGI has support directly through IIS and is not configured through an extension (i.e. Step 1.4 is not necessary and fcgiext.ini does not control FastCGI behavior for IIS 7+ and there is no need to create/edit it). Instead, make sure that CGI is enable under Internet Information Services in Control Panel > Programs and Features > Turn Windows Features on or off.
Web.config
IIS 7 is the first version of IIS to read configuration settings related to FastCGI from the Web.config file. Your Web.config file will need to contain, within the <configuration> element, a <system.webServer> element containing a <handlers> element containing an <add> element with the attributes:
path: *
verb: *
modules: FastCgiModule
resourceType: Unspecified
requireAccess: Script
scriptProcessor: the tricky one
The scriptProcessor Attribute
This attribute of the <add> element must contain the full path to the Python interpreter .exe file you want to use (the one in the Scripts subfolder of your Python virtualenv) followed by a | and then the full path to the wfastcgi.py file you are using. As these paths are dependent on the setup of the machine on which your app is running, you may want to have this attribute set as part of your deployment process.
IIS Server-wide Set Up
In inetmgr, click on the server node in the tree and then choose FastCGI Settings from the center pane. A list of executable/argument pairs will come up.
Add an entry for the full paths to your python.exe and the wfastcgi.py you are using. Both should be given the same way they show up in the <handlers>/<add> element in your Web.config.
Make sure to set up the PYTHONPATH environment variable in the new FastCGI application entry to include the root of your application codebase. The advice about adding an empty PYTHONPATH entry in the <applicationSettings> of your Web.config may not apply to this version of IIS.

You have hit the nail on the head there. Installing on Windows is kind of like trying to fit square pegs in round holes. Apache and mod_wsgi would probably be the best fit, but the whole experience is much smoother and straightforward (with pip, apt-get etc.) on a Linux box. Would a Linux VM running on the Windows server be a suitable compromise?

One potential pathway, though I foresee it to be very complicated, is having your flask app running in windows subsystem of linux.
There's existing tutorials on how to make calls to powershell scripts from the subsystem, e.g.,: https://www.raymondcamden.com/2017/09/25/calling-a-powershell-script-from-wsl

I am successfully using the simple Twisted Web server on Windows for Flask web sites.
Are others also successfully using Twisted on Windows, to validate that configuration?
new_app.py
if name == "main":
reactor_args = {}
def run_twisted_wsgi():
from twisted.internet import reactor
from twisted.web.server import Site
from twisted.web.wsgi import WSGIResource
resource = WSGIResource(reactor, reactor.getThreadPool(), app)
site = Site(resource)
reactor.listenTCP(5000, site)
reactor.run(**reactor_args)
if app.debug:
# Disable twisted signal handlers in development only.
reactor_args['installSignalHandlers'] = 0
# Turn on auto reload.
import werkzeug.serving
run_twisted_wsgi = werkzeug.serving.run_with_reloader(run_twisted_wsgi)
run_twisted_wsgi()
old_app.py
if name == "main":
app.run()

I recommend the following approach:
IIS
... with the IIS CGI/FastCGI module enabled
... using the wfastcgi python module to host a Python WSGI web application under IIS FastCGI
When correctly set up, deploying a Python web app on IIS is very easy, and can be done without clicking around in IIS admin, simply be editing the site/apps web.config file.
Documentation: https://pypi.org/project/wfastcgi/
Source code: https://github.com/microsoft/PTVS/tree/master/Python/Product/WFastCgi

IIS Not Linking to Django with PyISAPIe

I'm trying to run a site with Django on an IIS-based server. I followed all the instructions on the main site (http://code.djangoproject.com/wiki/DjangoOnWindowsWithIISAndSQLServer), and double checked it with a very good article (http://www.messwithsilverlight.com/2009/11/django-on-windows-server-2003-and-iis6/).
I successfully got as far as setting up IIS to read .py files. Following the main instructions, I can get the server to render Info.py. However, I can't seem to get IIS and Django to play nice. If, for instance, my Virtual directory is "abc", then if I go to "localhost/abc/", the browser simply shows me the content directory for that folder. Furthermore, if I have my urls set up so that "/dashboard/1" should bring me to a certain page, entering "localhost/abc/dashboard/1" gives me a "page cannot be displayed" error.
I'm fairly certain IIS simply isn't referencing or interacting with Django at all. Does anyone have any ideas how to fix this?
Thanks

Here are the original instructions I followed,
basics instructions: https://code.djangoproject.com/wiki/DjangoOnWindowsWithIISAndSQLServer
additional tips: http://whelkaholism.blogspot.ca/
The first thing you should do is install Python 2.5 or 2.6, for 2.7 you need to recompile PyISAPIe, which I have not done. http://www.python.org/ftp/python/2.6/python-2.6.msi
You need to install the version of PyISAPIe that will match your Python Interpreter version, if they do not match, it will fail. Get it there : http://sourceforge.net/projects/pyisapie/files/pyisapie/
Move the extracted folder from the last step at a decent location (i.e. C:)
You need to change the security settings of the PyISAPIe.dll, they suggest Network Service read, but I set everyone, to be sure there are no problems with this
You then have to CUT AND PASTE (Important) the Http folder of PyISAPIe to Lib\Site-Packages of your Python installation directory
Next, you setup IIS (open the manager with inetmgr in run (winkey+r):
Add a new virtual directory and allow executing ISAPI extensions when prompted by the wizard
Add a new wildcard extension in the property of your virtual directory, untick file exist setting
Add Web Service Extension to IIS Manager pointing to the dll, ensure it is allowed
From the PyISAPIe folder, copy examples\django\Isapi.py and paste it in Lib\Site-Packages\Http
In Isapi.py, set the path (i.e. c:\inetpub\wwwroot\ web_site\ django_project ) and DJANGO_SETTINGS_MODULE (i.e. django_app .settings)
When any change is done to your files, use iisreset in your command prompt to apply the changes
Here are some other things you might do
Ensure the path of your db file (if sqlite used) is okay
Do the same with template location settings
In your urls and html files, ensure the path start with the name you gave to your virtual directory alias (i.e. web_site in our example)
Finally, you may encounter difficulties with serving your CSS. If you have any troubles, tell me and I will update my post.

Serving Django with any webserver basically involves three key details:
Telling the webserver, "I want you
to serve content that is provided by
this module that invokes python"
Telling the python module, "I want you to execute python code
using the details in this file"
Telling the file, "I want you to use Django"
If you're getting a directory listing back for your Virtual Directory then it would seem that you should investigate the VD settings to make sure PyISAPIe is configured for that directory (key details #1).
From the article you mentioned:
Open the IIS Management Console, and create a new virtual directory, and
allow executing ISAPI extensions when
prompted by the wizard.
View the properties of the new folder and click on the
"configuration" button (if it's greyed
out, click 'create' first), then add a
new wildcard extension (the lower
box), locate the pyisapie.dll file and
untick the "check that file exists"
box.
In the IIS Manager, go to the "Web Service Extensions" section, and
right click -> add new web service
extension.
Give it a name (it doesn't matter what), add the pyisapie.dll
fill as a required file and check the
box to set the extension status to
allowed.