One could perhaps let the installer patch the hardcoded parts in the packages of the site-packages folder to whereever the user wants to install the stuff… That is what afaik Eigenlabs did - so they could just uncompress the packages to that specified location with the EigenD installer. Unfortunately the packages installed to site-packages via pip have hardcoded paths in them, so one can only run a copy of a site-packages folder at exactly the same path location where it was installed to. (Dependency resolution in pip is pretty basic, but there are more sophisticated solutions like poetry). And then there are package managers like pip that (optionally) download and install all these dependencies recursively. And Python programs are then distributed as packages that have a list of their dependendencies in the bundled metadata (the wheels). Usually there is a (small) set of system libraries that are supposed to come with any Python 3 installation. I guess this “framework” is essentially a Python distribution that comes with a number of pre-installed libraries (similar to Anaconda)? I don’t know the specific situation for macOS. This approach, means we will be less dependent on future Apple OS updates providing different versions of Python. (*) as we will also need to update the windows to python3 too, and I highly doubt windows has a python install ‘out of the box’ĮDIT: Apple are currently supplying Python 3.8, having reviewed seeing some of the changes post 3.8… Ive decided we should go straight to the latest Python (3.10.5), and so will require users to install from Its not ideal, as an extra install step, however, there are some benefits to this route, as it could be the same/similar for Mac and Windows (*) which we have previously done for the 64bit version. ![]() If we can’t figure it out, then probably I’ll got down the route of getting users to install from. ) will install in /LibraryĪgain, why Apple moved from a ‘framework’ to this simple /usr/bin/python3 is a bit unclear to me… and really the post is above the implications of this. ![]() Iirc, apple will install things in /System/Library, and 3rd party (e.g. I admit, I was being lazy, I didnt go check … and my machine had it installed in both /Library and /System/Library Yeah this is all post macOS 12.3, as Apple removed it, and hence the issue created/discussed here (and no, I dont want to use an installer and supply python to install on users machines, thats approach of runtime packages was horrible from eigenlabs ) Ideally, id use whatever is in place on macOS i Ok, to be clear… I know we could (all) just download/install Python package from ,īut thats an extra step for users… so its not ideal. So Im wondering, is the (python) development model on to compile against the Xcode framework, but then users run against /usr/bin/python3? (and that doesnt work anyway due to rpath, but lets ignore that for now ) ![]() Now thats ok for development, but obviously I dont want users to have to install Xcode to run EigenD. Applications/Xcode.app/Contents/Developer/Library/Frameworks/amework/Versions/3.8/Resources/Python.app/Contents/MacOS/Python So EigenD compiles using the amework.Īnd so in my current dev for python3, Im using the framework supplied by Xcode. When is it enough to just have the python3 executable, vs the framework? This framework has now gone, BUT we have /usr/bin/python3 (need to double check, but thats not the point of this post) Or might have been /System/Library/Frameworks/amework This is a bit of a general question for those familiar with Python on macOS…
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |