I have Python 2.7 installed in "C:\Python27". Now I run 1st demo of Python4delphi with D7, which somehow uses my Py2.7 install folder. If I rename Python folder, demo can't run (without error message). I didn't change properties of a demo form.
What part/file does py4delphi use from my Python folder?
python4delphi is a loose wrapper around the Python API and as such relies on a functioning Python installation. Typically on Windows this comprises at least the following:
The main Python directory. On your system this is C:\Python27.
The Python DLL which is python27.dll and lives in your system directory.
Registry settings that indicate where your Python directory is installed.
When you rename the Python directory, the registry settings refer to a location that no longer exists. And so the failure you observe is entirely to be expected.
Perhaps you are trying to work out how to deploy your application in a self-contained way without requiring an external dependency on a Python installation. If so, then I suggest you look in to one of the portable Python distributions. You may need to adapt python4delphi a little to find the Python DLL which will be located under your application's directory. But that should be all that's needed. Take care of the licensing issues too if you do distribute Python with your application.
Related
I was wondering If any one could help me to understand the difference of python virtual environment and docker container.
So I would like to have environment for each tools isolating from each other to avoid dependency conflict for example: use of different version of same dependency causing error in one of the tool because one tool need older version and other one requires newer version.
I’m tested out python venv but not sure if it’s the right one I should use for the issue I just explained or docker is something I should be using for my situation?.
Particularly for day-to-day development, prefer a virtual environment if it's practical.
Virtual environment
Docker
Works with native tools; can just run python myscript.py
Requires Docker-specific setup
Every IDE and editor works fine with it
Requires Docker-specific IDE support
Can just open() data files with no special setup
Can't access data files without Docker-specific mount setup
Immediately re-run code after editing it
Re docker build image or use Docker-specific mount setup
Uses Python installation from host
Use any single specific version of Python
Isolated Python library tree
Isolated Python library tree
Uses host version of C library dependencies
Isolated C library dependencies
A virtual environment acts like a normal Python installation in an alternate path. You don't need to do special things to make your local code or data files available; you can just run your script directly or via your IDE. The one downside is that you're limited to what your host OS's package manager makes available for Python versions and C library dependencies.
A Docker container contains the filesystem of a complete OS, including a completely isolated Python installation. It can be a good match if you need a very specific version of Python or if you need host OS dependencies that are tricky to install. It can also be a good match if you're looking for a production-oriented deployment setup that doesn't specifically depend on installing things on to the target system. But, Docker by design makes it hard to access your host files; it is not a great match for a live development environment or especially for one-off scripts that read and write host files.
The other consideration here is, if you use the standard Python packaging tools, it's straightforward to run your program in a virtual environment, and converting that to a Docker image is almost boilerplate. Starting from Docker can make it tricky to go back the other way, and I see some setups around SO that can only be run via Docker; if they were restructured to use a standard setup.cfg/requirements.txt installation setup they would not require Docker but could still be used with it.
GitHub recently released a container registry alongside their package registry. What is the difference? When would it be better to use one or the other? Do we need both?
Packages are generally simple: they are essentially an archive (i.e. zip file) that contains contents (code libraries, application executables, etc.) and a manifest file (json document, xml file, etc) that describes those contents with a package name and version number (at a minimum).
ie:- npm,pip and composer packages.
Container images are also simple, but they're more like an archive (i.e. a zip file) than a package.
ie:- nginx, redis etc
Verdict:- if some libs repetitively used in any project then we can create package and use in project .while for all project based dependencies we need to choose container to run this. Yes we need both.
After debating this with a Docker-using friend for a while I think I've found a satisfactory explanation:
Packages are for modules of code which are compiled together into an
Application.
Containers are for Applications which are compiled together into a
Server.
This is a bit confused by the fact that a Package can contain a standalone Applications, and Containers will often use package managers like Apt to install these applications. I feel like this is an abuse of package management due to a legacy where we didn't have Containers. Eventually I would expect most Applications will be delivered in Container form.
What is The Correct(tm) way for an Electron application to run both as a desktop application and as a service?
I have looked high and low for this but to no avail. This is how I think it should work.
Create a launchd/systemd/windows service description that:
Sets ELECTRON_RUN_AS_NODE environment variable
Runs the packaged Electron application
Produces happiness?
Can the packaged Electron application run in this manner access the contents of the ASAR file? If it can, great.
Then just build and package two directories with the application. Both compiled for the ABI version Electron is on:
Directory electron_modules with binary modules compiled for an executable that reports being electron
Directory node_modules with binary modules compiled for an executable that reports being node
With the appropriate NODE_PATH also set in the service description, I should be all golden.
Right?
I am not 100% sure what the OP is asking but I found this question while looking for: how do I run an Electron application as a desktop application and also as a CLI service with no access to a display driver?
The answer from here is
Being based on Chromium, Electron requires a display driver to function. If Chromium can't find a display driver, Electron will fail to launch ... In essence, we need to use a virtual display driver.
The solution (on linux at least)
Install xvfb
Prefix your start command with xvfb-run e.g. xvfb-run node_modules/electron/dist/electron .
Our requirement is to create a container for legacy apps over docker.
We don't have the operating system support/application server support available, nor do we have knowledge to build them from scratch.
But we have a physical instance of the legacy app running in our farm.
We could get an ISO image from our server team if required, our question is if we get this ISO image can we export this as a docker image?
if yes, please let me know if there is any specific procedure or steps associated with it.
if no, please tell me why? and the possible workarounds for the same.
if we get this ISO image can we export this as a docker image?
I don't think there is an easy way (like push-the-export-button) to do this. Explanation follows...
You are describing a procedure taking place in the Virtual Machine world. You take a snapshot of a server, move the .iso file somewhere else and create a new VM that will run on a Hypervisor.
Containers are not VMs. They "contain" all the bytes that a service needs to run but not a whole operating system. They are supposed to run as processes on the host.
Workarounds:
You will have to get your hands dirty. This means that you will have to find out what the legacy app uses (for example Apache + PHP + MySql + app code) and build it from scratch with Docker.
Some thoughts:
containers are supposed to be lightweight. For example one might use one container for the database, another one for the Apache etc... Your case looks like you are moving towards a fat container that has everything inside.
Depending on what the legacy technology is, you might hit a wall... For example, if we are talking about something working with old php, mysql you might find ready-to-use images on hub.docker.com. But if the legacy app is a financial system written in cobol, I don't know what your starting point might be...
You will need to reverse engineer the application dependencies from the artifacts that you have in access to. This means recovering the language specific dependencies (whether python, java, php, node, etc). And any operating system level packages/dependencies that are required.
Essentially you are rebuilding the contents of that ISO image inside your docker file using OS package installation tools like apt, language level tools like pip, PECL, PEAR, composer, or maven, and finally the files that make up the app code.
So, for example: a PHP application might be dependent on having build-essential and php-mysql installed in the OS. Then the app may be dependent on packages like twig and monolog loaded through composer. If you are using SASS you may need to install ruby as well.
Your job is to track all these down and create a docker file that reproduces the iso image. If you are using a common stack like a J2EE app in tomcat, or a php app fronted by apache or ngnix, there will be base docker images that will get you most of the way to where you need to go.
It does look like there are some tools that can do this for you automatically: Dependency Walker equivalent for Linux?. I can't vouch for any of them. But you can also use command line tools. For example this will give you a list of all the user installed packages on a fedora system:
sudo dnf history userinstalled
When an app is using a dependency manager like composer or pip, there is usually a file that lists all the language specific dependencies.
At the end of the process you'll have a portable legacy app that can be easily deployed anywhere with a minimal footprint.
As one of the comments rightly points out, creating a VM from the ISO image is another way forward that will be much easier to accomplish. The application dependencies won't be explicit, but maybe that's ok for your use case.
I'm working in an Erlang environment. I'm looking to establish a dependency manager so that our build server can publish binaries for reuse instead of using source code dependencies. The Hexpm GitHub project implies that it is possible to run it outside of the hex.pm website, but I don't see any instructions for doing so. Specifically, I would like my build server to be able to publish packages either directly (via the filesystem) or via rebar3, and for subsequent rebar3 builds to be able to use those published packages
Is it possible to run Hex on my own server?
If so, where would I find some documentation on how to set it up (or provide the instructions directly)?
If you look at https://github.com/hexpm/hex_web there are instructions in the README.md for both installing and running it. It's a phoenix application, so it should all be relatively familiar ground if you've looked at the phoenix framework before.
As for getting rebar3 to work with your installation, there is documentation here as to the config values to use for setting the URLs to use for hex packages: http://www.rebar3.org/docs/hex-package-management.
HTH.