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
https://github.com/blueman-project/blueman
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
nov25-1@nov251-desktop:/usr/bin$ blueman-services
nov25-1@nov251-desktop:/usr/bin$ blueman-tray
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? )
Thanks
@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 automake and 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:
*.py linguist-language=Python
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.
Thanks again.
Closed ??