Qpm: A package manager for Qt
qpm.io
qpm.io
1. Use the system package manager.
2. See rule #1.
In all seriousness, there needs to be a good way to [spray your stuff](http://dilbert.com/strip/2013-06-09) all over a system with the rest of the system knowing about it. FPM does a decent job of this.
There is some research out there on common things that this kind of code gets wrong: https://www.cs.arizona.edu/stork/packagemanagersecurity/
This could be 1000 x as much work for not much gain.
Then you have a bunch of developers all taking the easy way. And now all the system administrators running systems with those projects can't trust their packaging tools anymore, and have to do a lot more work in their daily workflow.
Oh, and as a bonus, none of these systems have a secure update mechanism, so you've bypassed the inherent code whitelisting that comes with a system package manager with a centralised repository and a requirement for strong package signatures. At best, they do like PyPi and optionally allow a developer to specify a GPG key. So you have to do "pip install <bla>" and pray to the computer god that the developer of <bla> and all the developers of all its dependencies cared about code integrity and set up GPG keys. From experience, the chances of that are approximately 0%, because it's not a requirement.
This doesn't work so well for micro-dependencies, though. The TeTeX distrib. in Fedora is bad enough, I'd hate to see the same done with node packages.
A much better solution would involve making languages like Python accept the Python version as a dependency while making building the PYTHONPATH more flexible with common tooling. Making PYTHONPATH building better would enable installation with namespace+version, such that we could have:
/usr/lib/pymodules/requests/1.0.0/...
/usr/lib/pymodules/requests/1.2.1/...
/usr/lib/pymodules/python/2.7.10/...
/usr/lib/pymodules/python/3.5.0/...
May sound weird, but take a look:
https://www.gnu.org/software/guix/
The main distribution will only ever have free/open source software in it but it is trivial to make your own packages/package repositories and share them since it is just a guile code file.
Addendum: I'd might as well mention that PEP 3147 is implemented from Python 3.2 onwards, so for Python 3, some of the problem is solved.
You still have the issue of being able to install different version of the same library.
This is certainly better than it was (.pyc files just didn't co-exist sanely across python versions), but it doesn't provide a method for running multiple versions of libraries between different apps.
Far from it. It's up to the system package manager to generate the .pyc files for the globally installed version of the libraries. __pycache__ directories allow this to be done cleanly for any installed interpreter that supports them. It has all the information it needs, and users need not get involved.
Unless the user is running a copy of Python that wasn't installed by the package manager, there should be no need for them to cause the .pyc files to be generated. Besides, .pyc files are an optimisation so that parsing and bytecode compilation doesn't have to repeatedly happen, and aren't even strictly required: the result is slower startup, but it couldn't prevent the code from being run.
> it doesn't provide a method for running multiple versions of libraries between different apps
Indeed, and I pointed that out in my comment in the addendum. Virtual environments are still pretty much the state of the art in that regard, unfortunately. It's possible that some PYTHONPATH magic might help with that to some degree, but that would be messy.
No you are not. At this point, you have catered for developers in the language. You have not yet catered for final users.
Really, the Linux landscape is not that scattered. Package for Debian and Redhat and you have done the Pareto effort.
Anyone know the name of this tool? It was unmaintained for a long time already when I stopped using Linux, and that was 10 years ago.
%prep
%setup -q
%build
%configure
make %{?_smp_mflags}
%install
make install DESTDIR=%{buildroot}
%files
/usr/*
nix/guix is a sort of reasonable answer to this issue, I guess, but then you have to develop on nix/guix and hope that apt/rpm/pacman can handle your dependencies.
[1] http://www.gnu.org/software/guix/manual/html_node/Features.h...
[2] http://www.gnu.org/software/guix/manual/html_node/Invoking-g...
Then again, I've had good mileage out of making .debs that plonk dev work and deps into /opt locally. YMMV.
You should be so lucky as to have a program package manner be at all compatible with apt or yum.
When system package managers get properly documented maybe ... when instead of having 1 package manager per system , we have a single package manager for every system ... otherwise no, use the package manager that comes with the language if there is one.
Invalid complaint. The major package managers are extremely well documented. Even some of the minor ones, like archlinux.
Until then, I surely will not waste my time generating one package per OS/distribution flavor.
1) Use a monolithic library like lodash
2) Use a library for each function (note that lodash can also be used in this way but we are already far off-topic)
3) Inline these small functions.
So a website loading lots of monolithic libraries and using JS for everything is actually the opposite extreme for what caused that drama. If I'm wrong or irrelevant, please tell me how instead of down-voting please because I sincerely don't see how. Thank you.
I mean, you could also have it as a helper function in your project but that decreases the re-usability to copy-pasting across projects.
In the end, effective or not, I can see it as an attempt on reducing bloat. I see that many don't agree, but I'm afraid they don't take into account the constraints imposed by sending code to the clients rather than a binary.
Why, did you have to count the JavaScript scripts and/or volume? On a web browser JS loading is usually transparent, unless one opens the developer tools.
So, either the page was slow for you (a legitimate concern, but the same volume could be matched with 1-2 image assets, not particularly a JS issue), or there's absolutely no reason to care how many JS it loads -- especially given that it's a useful open source project to provide people with packages for Qt.
Seriously, what is going on with the OS vendors? Its like .. the Web came along and now nobody wants to build better operating systems .. shouldn't package management be a function of the OS? Its really just filesystem/tree management, and this really, really should be something we can use the OS for.
However, its just not happening. Language vendors have to solve this problem because the OS vendors are asleep at the wheel. I think its apathy - the browser has replaced the OS, and very poorly. Nobody wants to fix this problem, I guess ..
So, you're better off with a technology that needs you to manually manage packages and dependencies?
>Seriously, what is going on with the OS vendors?
What about them? What do they have to do with Node, QT, Python, and other communities with package managers?
OS X has the App Store for OS X apps, Windows has something similar, Linux distros have package managers for their userlands. Other projects have nothing to do with OSes schedules...
No, you're better off having a single well-integrated system package manager. Once you start stuffing shit into system directories behind its back you lose all oversight. You can't even answer a simple questions such as "where did this file in /bin come from?" anymore. You can't tell the package manager "verify all installed files in system directories with the checksums listed in the package managers database" because the package manager doesn't know all the files.
I agree with GP, I avoid projects that require me to use a third party package manager if at all possible. If only because none of them seem to understand the reason for code signing.
And wait for MS and Apple and your distro to keep up with ALL upstream changes? And have them approve what goes in there? Yeah, good luck with that...
>Once you start stuffing shit into system directories behind its back you lose all oversight. You can't even answer a simple questions such as "where did this file in /bin come from?" anymore.
You'd be surprised. E.g. brew files are in the Cellar dir, npm modules are in node_modules, global pip files are in their own folder, etc.
No package manager I use (and I use several, and all are quite popular) messes with system directories.
Yeah, you're pretty competent at remembering all that, because you have to, over and over again, re-build this ontology... probably as part of a job or profession. Therefore "its good for you".
But, outside that box, is a world where applications, developers, the operating system .. and most important of all: users, don't have to hire people such as yourself to maintain all that gluck. And in that world, the OS and Apps guys, when they build Frameworks, don't make the mistake of -DRY/NIH/RTW'ing themselves, over and over and over again (I count 4 in your list, but there are many, many more sorts of this kind of thing) .. ad infinitum.
It is a huge mess, modern software development. There is nothing efficient, effective, or 'intelligent' about everyone having their own idea about how to add packages to a system. We learn this, every single time some language-/tech-/stack-dejour forks off their own little mind about how this all should be done.
Its because there isn't such attention being paid by the people who assemble the operating systems, about the needs of .. what admittedly becomes a huge reason to stay 'stuck' on the OS. Once you get it all set up. And have a team of monkeys to keep it from falling over, just because someone did an install somewhere, touched a .file accidentally, didn't quite properly set up a BOGUS_ENV before doing configure, etc. and etc. and /etc.
So currently the "state of the art" is: Create a package for each OS (which means multiple OS'es of flavour "Linux").
I really wish their was a generic tool that would input a source tree and output packages for the most common package management systems.
Anyone?
What I would do if my language needed package management: write an abstraction for whatever package managers exist on the platform I'm targeting. So my 'package manager' would just be a smart shell around apt-get, or yum, or whatever.
Okay, this looks like an idea ripe for the attention ..
Until languages reach a stage where they have totally transparent interoperability - which is the ability to use a library in your language regardless of the language the library was written in - OS vendors have a monumental (impossible) task on their hands.
Windows tried this with COM and ActiveX and I don't think that succeeded entirely.
Things like CLR or JVM are a partial solution, but you can't expect a C++ programmer to work with the JVM or a C guy to make his hack compatible with CLR.
I guess the way we have it right now is the natural "best" way. Let's hope someone somewhere gets enlightened and enlightens everyone else.
But its really, really hard, it seems, to get everyone to agree to these kinds of standards and share things across the filesystem in a way that is easily maintainable by real people as well as automated systems. I don't truly believe all this new school of thought, either, about filesystems having to go away - to me this is just a cop-out by folks who should be taking responsibility for teaching people what a filesystem is (since we have so many of them) before we start throwing them away and replacing them with .. something .. which inevitably doesn't solve any of the filesystem problems, but does mean less code has to be maintained.
Which is why I think language-people do this "NIH"'ification of the problem: nobody is enforcing any rules, so Langage-X has to have its own way of laying things out, providing common code, isolating things into common/routine layouts, and so on.
It truly is, for me at least, that if your language requires package management, its broken and isn't any better than any of the other umpteen languages that preceded yours, no matter how sexy it is, and which also has "package management".
The whole are is just broken and isn't fixed yet. I don't know all the answers, but I have a feeling a good start might be "build an OS, an execution environment, and a user interface using one language and one language only, and make all sub-systems of that OS utilize a standard, built-in, intelligently designed means of handling dependency graphs for user sub-modules".
All of these worlds would be loading a ton of C++ QT base libs in any case.
Here's the current output at the time of writing: http://paste.debian.net/plain/432079
I am currently trying to implement that myself with the QML canvas, but it is not that easy to get a smooth working library.
Edit: There is not. But here is a list of current packages: https://github.com/Cutehacks/qpm/issues/28#issuecomment-2082...
If you will pardon me from being lazy and not looking at the source, is there a reason for that?
I see a lot of people here don't seem to get the purpose of this -- having played a bit with c++ and pkg-config[1] ... I assume that pkg-config is the kind of software this project tries to improve on? I can see how that might make sense for qt, which already has some properties of a runtime/standard-library (eg: qt string). And/or perhaps copy go's package management for c++/qt?
I suppose I can't really say I've seen the need that this project fills -- but I still wish it well :-)
As for the problem this solves; this is a package manager for Qt app development. It doesn't try to operate on a system level like pkgconfig. There's no system-wide shared code. Every app you are building has it's own copy of the code it needs locally like npm/node_modules. In addition to downloading dependencies, the tool generates some code to cleanly add it to your project without you having to mess with include paths or other settings. It also encourages things like proper namespacing (both C++ and QML) to avoid collisions.
Also - any reason why couldn't just use npm with Qt?
My guess is that these Qt people probably use an IDE and want to be able to immediately see what methods are available in the context of a QString. Then they want code completion as they supply parameters to it. That's so OO. (Ok the method is immutable and composable but its still blatant 90s object orientation)
https://code.woboq.org/kde/qt4/src/corelib/tools/qstring.cpp...