One option that you could consider is using a continuous deployment tool like Jenkins, Travis CI, or GitLab CI. These tools can automatically deploy your code to a production server whenever you push your code to a certain branch in your git repository. This can save you the time and effort of manually deploying your code to your production server every time you make a change. Another option is to use a service like Heroku, which makes it easy to deploy and manage your web applications. With Heroku, you can simply push your code to a git repository, and Heroku will automatically build and deploy your application. Ultimately, the best option will depend on your specific needs and preferences, so it may be worth experimenting with different approaches to see what works best for you.

You're trying to copy just the /venv directory, but that's not going to work. Take a look at the contents of that directory, for example: root@52bdcc57abd8:/# python3 -m venv /venv root@52bdcc57abd8:/# ls -l /venv/bin/ total 48 -rw-r--r-- 1 root root 8834 Oct 22 03:52 Activate.ps1 -rw-r--r-- 1 root root 1880 Oct 22 03:52 activate -rw-r--r-- 1 root root 829 Oct 22 03:52 activate.csh -rw-r--r-- 1 root root 1969 Oct 22 03:52 activate.fish -rwxr-xr-x 1 root root 222 Oct 22 03:52 pip -rwxr-xr-x 1 root root 222 Oct 22 03:52 pip3 -rwxr-xr-x 1 root root 222 Oct 22 03:52 pip3.9 lrwxrwxrwx 1 root root 7 Oct 22 03:51 python -> python3 lrwxrwxrwx 1 root root 22 Oct 22 03:51 python3 -> /usr/local/bin/python3 lrwxrwxrwx 1 root root 7 Oct 22 03:51 python3.9 -> python3 As you can see /venv/bin/python3 isn't actually a file, it' just a symlink to whichever version of Python was used to create the virtual environment. You won't get away with just copying the binary, either, because you need the full set of runtime files from /usr/local/lib/python3.9, as well as any shared libraries that are by required by Python. But when replacing base image with debian:11-slim everything works as expected. In this case, you're installing a compatible version of Python...but if you're going to do that, you might as well just stick with the python:3.9-slim image.

from googleapiclient import discovery from oauth2client.client import OAuth2Credentials as creds crm = discovery.build( 'cloudresourcemanager', 'v3', http=creds.authorize(httplib2.Http())) project = crm.projects().get(name="projects/"+projectId).execute() project_name = project['displayName']

So I found similar question (regarding installing, but works for publishing as well) https://stackoverflow.com/questions/73624685/install-python-package-from-private-artifactory-behind-vpn Basically, you can either setup GH Actions runner within VPN or use proxy to access your resorces. I have ended up using answer from comments my strategy would be to create a source code release zip file and publish it on GitHub and then download it from within the VPN to push it to the intern repository. github.com/marketplace/actions/create-github-release and still run separate job for publishing into internal repository.

I'm guessing you created and activated in your terminal? You need to tell vscode about the venv. It's pretty good at finding and using them but sometimes it dectects the wrong one. At the bottom of the vscode window you should see the environment listed. If its the wrong one click it and find the right one. Also your launch.json and setup file seems wrong. The program should probably be script or python3 ${file} in launch.json. In your setup file scripts should be scripts=bin/my-cool-program. Then you can change program in launch.json to my-cool-program. You should also be able to run it from your terminal like $ my-cool-program -q data. This is a great way to learn, but it's not how I would create a CLI program today in python. I think you would be better off using poetry and click. Here is an https://cjolowicz.github.io/posts/hypermodern-python-01-setup/ to "modern" python.

The driver used for the database connection should have connection settings that govern transaction behavior. The pyodbc driver for python, for example, has the “autocommit” setting. With autocommit set to “True”, the SQL Server session will autocommit transactions - each statement that opens a transaction will autocommit that transaction as it completes. Using the pyodbc driver, if autocommit is set to “False” the session will have implicit_transactions ON. A number of statements implicitly begin a transaction (unless the session is already within a transaction) in this mode. Note that some SELECT statements may avoid starting a transaction if they do not specify a table. Implicit transactions do not commit automatically when the statement which began them completes. Implicit transactions require a commit or rollback. More information about pyodbc here - but if using a different driver look for that driver’s documentation. https://github.com/mkleehammer/pyodbc/wiki/Database-Transaction-Management More information about implicit transactions here… https://docs.microsoft.com/en-us/sql/t-sql/statements/set-implicit-transactions-transact-sql?view=sql-server-ver16

Instead of a boolean attribute that shows if a row is being processed, add a timestamp with time zone attribute that you set to current_timestamp when you start processing a row. When looking for rows to process, add a WHERE condition like WHERE locked_at IS NULL OR locked_at < current_timestamp - INTERVAL '30 minutes' Then you have a lock that automatically expires after 10 minutes. If processing could take longer than 30 minutes, use a different interval.

Check your connection string. This Driver=Testserver should be DSN=Testserver if you're using a DSN. Otherwise use a DSN-less connection string.

UIs (such as Workbench) silent tack on a LIMIT to constrain the amount of output. This speeds up certain queries. I suspect this explains the alleged difference. Running the 'same' (or, in some cases, 'similar') twice in a row -- the second one may be much faster than the first. This is due to "caching". Run your queries both ways again. I suggest you look at SHOW CREATE TABLE; you may find that the table is not really ENGINE=MyISAM. 8.0 is seriously deprecating that old Engine. I recommend you take the hint and move to InnoDB. "long it takes to bring the data" -- That sounds like it includes the web page rendering. Instead, add code to actually capture the time before and after.

SELECT MAX(pincode1) AS pincode1, MAX(pincode2) AS pincode2, city FROM tbl GROUP BY city;

There was a https://github.com/termux/termux-packages/issues/10808#issuecomment-1137229251 . To install the up to date version of numpy (1.22.4), simply run MATHLIB="m" pip install numpy And numpy wheel will be build normally. Your second error (with [...]/https) seems an Internet connection problem, but not sure.

May be you can do something like, get the current working directory and then combine it with your folder/filename to dynamically store your screenshots and logs in a specific folder relative to your project directory. I've used something like this in Java, System.setProperty("webdriver.chrome.driver", System.getProperty("user.dir") + "//chromedriver"); System.setProperty(FirefoxDriver.SystemProperty.BROWSER_LOGFILE, "FFLogs.txt"); File file = new File(System.getProperty("user.dir") + "//data/report-" + currentDate + ".csv"); String logFile = "./Target/Result-" + currentDate + ".jtl"; You can figure out something on the same line in Python with, driver.save_screenshot('./project_directory/save_screenshot.png') for storing in your current project/code directory. Note: I haven't worked with Python personally. But, you should be able to get the current directory and combine it as a string to the filename and parse it to save your screenshot/logs.

You can use https://github.com/SeleniumHQ/docker-selenium#video-recording that Selenium provides for video recording. Since you use docker images in "remote driver" manner you can use those images from python code as well.

Are you familiar with either language ? Are there co-workers or mentors that use either of these languages ? These are the types of questions you need to answer. Either language works fine with Selenium. If you are starting from scratch with no resources, I guess I would start with Python. The learning curve should be easier and the tutorials on the web should be more recent. Disclaimer --- I prefer Java but have been using it for a long time.

Since you have shared that there are no lookup errors or no such window exception, I think it might be an issue related to waiting time. This is why when you are running an individual test, it works fine. However, when you must be running multiple tests together, no wait time between the tests restricts the elements in the script to load. Let me know if you have added the wait time in-between the tests. And if adding wait time resolves your issues, I would like to hear it too. Also, here I am sharing a link for a similar query that I think might help you solve the problem https://www.typemock.com/answers/9694/running-all-tests-fails-some-tests-that-pass-individually

I think that I understood, and I had similar problem sometimes. So in this case I make a screenshoot and I take the xpath. Advice you need to use xpath simpler, use descendant,... Later I think you will have a new problem because this element only it's activated when the mouse is on the button, so you will need to use the library Actions ( https://medium.com/analytics-vidhya/python-selenium-all-mouse-actions-using-actionchains-197530cf75df ) to move it

Winappdriver can start executables (generally .exe files on Windows) I suspect your .msc file is a management saved console? If so, your actual executable would be mmc.exe (see e.g. here: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/mmc ) and your msc file an argument passed to mmc. I cannot test this, but I suspect something along these lines should solve your problem: from appium import webdriver desired_caps = {} desired_caps["app"] = "Wherever mmc is on your system\mmc.exe" desired_caps["appArguments"] = "C:\Desktop\vit extended\vit.msc" desired_caps["platformName"] = "Windows" driver = webdriver.Remote("http://127.0.0.1:4723", desired_caps)

1+GB size for a table with 2k rows means either it has huge text columns or it is highly bloated. Why don't you try running vacuum (analyze, full) against the database in question (if you haven't already done that) and re-check the size of your table again? VACUUM reclaims storage occupied by dead tuples. In normal PostgreSQL operation, tuples that are deleted or obsoleted by an update are not physically removed from their table; they remain present until a VACUUM is done. Therefore it's necessary to do VACUUM periodically, especially on frequently-updated tables. Reference: https://www.postgresql.org/docs/current/sql-vacuum.html (PostgreSQL | Docs)

So this worked for me. I am relatively new to operating systems, so idk if there are any consequences that I'm unaware of. my solution: in terminal run: lsof -i:5432 sudo kill [PID] then rebuild the image and restart the container.

If one were to refer to the https://www.postgresql.org/docs/14/app-pgdump.html , one would discover that The -n and -N switches have no effect when -t is used, because tables selected by -t will be dumped regardless of those switches This seems to be exactly what is happening in your case. Contrary to what your comment says (--table="lime*" // redundant because), that switch actually overrides your schema specification. You should omit --table.