How do I find actual executable AFTER I clone code from github?
just after cloning the official python repository ? Well, nowhere, the repository contains only source code.
You need to build it as shown in the Setup and building chapter of the Python Developer’s Guide.
Thanks for reply. I am using PyCharm and using its option “clone” using the link given in github. That apparently is not same as “fork”. I prefer NOT to use “fork” since fork creates an entry in github, no need to make others users aware about what I am doing - for now. Now I have a source code project in PyCharm. Is that correct? Since Python is interpreted language I should be able to “run” such project ? Perhaps PyCharm will do the “build” if I select correct file and that is what I am missing - what is the “main” Python file / module to let PyCharm process the source code.
If you build Python in your local clone, the location of python.exe or version thereof depends on the OS. Look at the OS specific build instructions in the ‘Using’ doc.
Now I have a source code project in PyCharm. Is that correct?
Yes. PyCharm would infuriate many users if its ‘Clone’ did something different to ‘git clone’
Since Python is interpreted language I should be able to “run” such project ?
Not necessarily. The project in question is a clone of CPython. As its name implies, it is a C Project. Its very purpose is to be the foremost thing that interprets the Python language (other implementations of the Python language exist, such as…). By the way, technically CPython is a compiler (to Python byte code) that runs your compiled code in a VM.
PyPy Is a Python Project (written in Python) that runs Python code. But it’s a JIT compiler not an interpreter.
Common, I am not looking for Python.exe…
This is getting too confusing.
(Is it on purpose so nobody can duplicate Bluetooth manager ? I though it is open source… )
Is “Bluetooth manager” written in C or Python ?
Either way - I need to be able to run it in my choice of tool - either C or Python.
What is “bluetooth manager”? This was the very first occurrence of the word “bluetooth” in this entire thread. Did you mean to include a link to a repository for “bluetooth manager” in your first post? If so it did not come through at all, which I expect is the source of confusion here.
When Python code is cloned into local repository , you can identify cloned application main executable (script / module ) …
… now fill in blank here …
Every project is different, there’s truly no way to answer that question in general: some projects are pure libraries with no executables, some projects install multiple executables. Of those that install executables, some might define a
main function somewhere, or have a
__main__.py module, but there is by no means any guarantee of that. Also the executable might be a literal script checked into the repo that gets copied over to a bin directory, but it might just as easily be something that the build system auto-generates at install time, based on some build-time entry-point configuration, that does not “exist” in the repo at all. Speaking of build systems, there are at least a half a dozen reasonably popular build systems at the present time, all with different ways to be configured…
Your best bet here is to actually link to the specific project in question and describe what it is you actually want to accomplish in some actual detail, so that folks with experience can try to leverage that experience to help you. Otherwise, the only real suggestion available is “poke around some”.
Bryan, thanks for the reply.
I think this is becoming the proverbial “can of worms”.
All I was trying to do is to get local copy from github.
I finally figured out the main executable - “blueman-manager” - that actually runs - sort of…
Now I need to find how to get from “blueman-manager” to the actual source code.
My main reference is
and it is not much help in replicating source code.
I did run the “clone from github” and now I have to find how “blueman-manager” translates to the actual source code.
It looks as the application has several indepedent “main” (execuatble) files, so it I should be able to find it - perhaps some kind of “modules” structure.
nov25-1@nov251-desktop:/usr/bin$ whereis blueman-manager
blueman-manager: /usr/bin/blueman-manager /usr/share/man/man1/blueman-manager.1.gz
I am sorry , but I am not sure if I should create a new post or continue here , but this should be a few simple questions.
My task WAS to clone (local repository) , using github link, JUST the source code.
Unfortunately no matter what I try I cannot fully execute the cloned code – mainly I am missing the final GUI.
Initially I was not sure I have all the “prerequisites” also.
So - I decided to “fork” …
Before I do that - is it easy to delete the fork later ?
I do not want to create unnecessary garbage.
Does “forking” include the prerequisites ?
( Is “copy the main branch only” OK? )
@anneranch wow even by the standards of the range of possibilities I gave above, this project is way, way out in left field. It is not using any of the common build systems for Python packages, at all. It has a completely custom setup using tools like
autoconf that are normally used for C or C++ projects (and even there, almost obsolete… I haven’t encountered
automake in 15+ years, AFAIK folks have moved on to
cmake these days).
I took a quick look and I really have no idea. It doesn’t help that some of the installation instructions don’t seem to match the repo (e.g. there’s a
configure.ac but no
./configure that could be run). I think in this unique and highly specialized case your best bet really is to just do what the README suggests and go to the source of relevant expertise directly for your questions:
Feel free to open a GitHub issue to file bugs, or ask about anything you need help with.
From the README:
To install a packaged release of blueman, run `./configure && make && make install`. To generate and run a configure script from source, run `./autogen.sh`.
This is a distinction that you might not have picked up on, but a “packaged release” is one of these whereas the “source” is what you get when you clone the git repository. So in your case, it’s the second instruction that you want, which is going to generate all the files needed.
It’s quite common for the source files to require quite a few dependencies for building, but for a packaged release to require fewer. (Sometimes this even includes tricky dependencies like “a recent build of this exact project”.) Sometimes, it’s easier to just take the released version.
But the reason you’re seeing all of this is that… this is not just a Python package. It’s a fully compiled C project that requires Cython and a bunch of C libraries. So it makes sense that it uses a C-style build system (I’m not sure that automake counts as “obsolete”, and there are quite a lot of projects that haven’t moved on to cmake - and good reasons for not moving). But yes, it does make things harder.
@Rosuav I am aware of all of those things, but in fact nearly all of the repo is Python, the C portion is minuscule:
Given that I’d expect a “standard” Python build system to be the main driver, e.g. setuptools-based or Hatch or maybe scikit-build.
Maybe you mean this is just a front end for some separately distributed C-library. Sure, but I’d still expect Python tooling for building and distributing the nearly-all-Python part that is this repo.
Yeah, I think the proportions of files don’t really tell the whole story here; also, I think GitHub is seeing Cython input as Python, where it’s somewhere between that and C. But even so, there’s no particular reason to use a Python-based toolchain here, any more than the CPython sources have to be tracked in Mercurial just because it’s written in Python. (The built products, however, should be more Python-installable; but that’s the release, not the source.)
This is a weird non-sequitur and not analogous to what I said at all. I never suggested the build toolchain needs to be written in Python. scikit-build is not purely written in Python. I suggested that common python-project build tools might be appropriate for building a project largely written in Python. I guess we can disagree on that, but hopefully everyone would agree that if the project did use common python-project build tools, then identifying the entry points would be simpler for @anneranch if only because then would be docs and analogous projects and relevant support question answers to refer to.
In one of my Python projects, I set all the Hashbangs to point to a custom awk command, to print line 3, the first line after the encoding declaration, a simple message to direct command line users to the required host application.
Github then thought my thousand line Python project was 90% awk!
#! /usr/bin/awk NR==3 # -*- coding: utf-8 -*- # This module requires ....
This can by overridden by adding a
.gitattributes file with:
OK sure, GitHub’s language detection can suck sometimes. But really in this case it is almost all Python (which is obvious from spending 30 seconds actually looking around directories, I just thought the image would convey t the quickest):
base ❯ cloc HEAD 372 text files. 315 unique files. 188 files ignored. github.com/AlDanial/cloc v 1.94 T=0.83 s (379.5 files/s, 277631.0 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- PO File 60 37830 49535 82117 Python 147 17694 336 33168 SVG 17 3 6 3713 Glade 12 0 24 2396 make 59 227 3 819 Markdown 3 178 0 484 m4 2 70 29 350 Meson 4 50 19 340 C 1 82 25 316 XML 4 1 0 228 Cython 1 73 3 224 Bourne Shell 2 13 1 32 C/C++ Header 1 3 0 27 Text 1 0 0 8 Properties 1 0 0 2 ------------------------------------------------------------------------------- SUM: 315 56224 49981 124224 -------------------------------------------------------------------------------
My point is that this:
bluemandir = $(pythondir)/blueman/bluez/obex blueman_PYTHON = \ AgentManager.py \ Base.py \ Client.py \ Manager.py \ ObjectPush.py \ Session.py \ Transfer.py \ __init__.py CLEANFILES = \ $(BUILT_SOURCES) DISTCLEANFILES = \ $(CLEANFILES) clean-local: rm -rf *.pyc *.pyo
is not a common or unsurprising approach for building Python projects.
The Power of AI!
Well, it is getting little off the subject…,
I do appreciate all the help rendered,
but I came to a conclusion that this "Bluetooth manager “?” application is impossible to duplicate. Part of the problem is that I have installed true running code from Ubuntu repository and the source code given by github is apparently NOT the same as published in Ubuntu repository.
On top of that the “discussion” in the github is just copies of what is published and of no real help.
And more - the application - is just another version of BlueZ - with very rudimentary GUI.