A few points:
First, while I love some aspects of the Python language, I do have to agree that as a development platform, it is as shaky as the San Andreas Fault. I would agree that it is amateurish in many places, especially in regards to things like package deployment. It is better than most, open-source or closed-source, but it still sucks and is something of a mess.
However, to
paraphrase The Brain paraphrasing
Orson Welles (NSFW), if you can find a jury that would state that there is
anything in the IT field that isn't pure amateur hour, I will make cheese for you. No one in this field
even knows how to build professional-quality software yet, and it won't be until well after your grand-children's grand-children's time that anyone will. Any claims to either professionalism or engineering standards at this stage are laughable.
We, as a field, are at the equivalent level of Neolithic villagers building mud huts, and you want to build an aluminum cantilever bridge - a very small one, yes, but still one which requires knowledge no one has yet. If Python's package system sucks, it is because
every package system today sucks - indeed
every program to date sucks, and that will continue to be true for the foreseeable future.
More to the point, FOSS is amateur
by definition. You shouldn't be using FOSS software at all unless you are willing to commit the time needed to adapt it, and can afford to work within an open license framework for the parts that are FOSS. Otherwise,
don't use FOSS.
And no, I don't care one whit about the rhetoric of open-source versus closed-source. None of that really applies once commercial interests are involved in the software's production and distribution - because the point of FOSS isn't that it isn't distributed on an exclusively commercial basis, it's that the source code should be available to be inspected by outside parties to ensure that the engineering of the code (such as we can manage with our mud huts) is up to par. Unfortunately, as you've seen, that theory conflicts with the actual practice of software development by amateurs, where usually only those parts which are 'interesting' get proper effort.
This isn't really the point, though. The point is that while it is possible to use FOSS tools and even FOSS libraries in commercial projects, it takes a lot of effort to make it work without breaking either the code or the licenses, and for such projects a closed-source solution is often better - even if it is technically inferior to the FOSS solution, because the technical issues pale in significance to the legal, cultural and interpersonal ones.
Actually, interpersonal communication issues overshadow everything else in
any non-trivial software project, but that's another topic altogether.
In any case, there is a closed-source compatible implementation of Python from ActiveState called
ActivePython, which I understand fixes a lot of these issues - but only for their own packages and those they support.
In other words, whoever decided to use a FOSS toolchain didn't do their due diligence.
Second, there is the question of
why the project requires bbfreeze, or more specifically, why it requires a binary executable. This is not at all standard practice in the Linux world, or anywhere else for that matter, when working with Python. Let me be blunt - if you need a binary executable, you shouldn't be using Python. It is simply the wrong tool for the job, because the 'executable' you will end up with will just be a wrapper around the Python interpreter anyway, plus the bytecode-compiled Python program - it will bloat your project with code you don't actually need, and do nothing to prevent RE that just using a .pyc wouldn't.
Turning the .pyc file into a data section of an ELF file? Not a great plan - and as far as I can tell, that's exactly what tools like bbfreeze, cx_freeze, and (on Windows) Py2Exe do.
While it is possible to compile Python - or any other language - into an executable, in the case of a language which has and uses live code interpretation (
exec() and the like) the executable will need to include the interpreter, at least if the program uses it. As I understand it, Python programs use it a
lot internally, even if it isn't used explicitly, meaning that the interpreter would still end up bundled into any compiled package.
It looks as if this whole issue of building an executable is meant to support closed source software distribution, which means you shouldn't be using the CPython toolchain (the most widely used FOSS implementation, and presumably the one you are working in) at all - you'd be distributing the interpreter inside a closed source package, which is a non-no. If you can't distribute source, don't use a language that requires you to distribute source for part of the package.
In other words, whoever decided to use Python in particular didn't do their due diligence.
Third, @ggodw000 never mentioned which version of Python the project was using. This is relevant because if it is in Python 3.x, the package won't work no matter what. Despite the insistence of others to the contrary, Python 2.x and Python 3.x (and similarly, Ruby 1.x and Ruby 2.x) are better treated as separate languages, rather than versions of the same language - going from 2.x to 3.x entailed almost as many changes as going from, say, Pascal to Modula-2. Again, this is stated very explicitly in the documentation on PyPi.
So, if it is a Python 3.x project using a tool that doesn't work in Python 3.x, that's a due diligence problem again.
Finally, @ggodw000 mentioned the various and admittedly contradictory Python packaging systems, which seems to really be the crux of this matter. There are two problems here, however. First, the whole Python ecosystem is sort of caught in the middle of a very slow moving shift between two standards,
Egg and
Wheel. Egg is much older, the design of it is a bit sloppy, and the format is not very well standardized, while Wheel is much better designed and
documented but the implementation isn't really ready for prime time. Only about a third of PyPi projects have moved to Wheel, to date.
While the primary distribution tool for CPython, pip, supports both, they don't play nice together a lot of the time much as RPM, Portage, and .deb files don't. It is usually easier to convert an Egg to a Wheel yourself rather than trying to get them to work together. This is something that most Python documentation covering them mentions.
This is something that you should have been aware of before committing to using Python, in the process of determining how to conduct the project. Should I repeat what I said earlier?
So tell me again: who is it that is being unprofessional here?