Am 12.03.2013 01:23, schrieb Robert:>>
I see a number of issues with the build process and cyclic dependencies. As one example, just assume that both such dependencies are compiled as a shared library and think about how linking will work.
I actually thought of this. The solution I had in mind was, as that packages with cyclic dependencies are virtually an inseparable entity they just would be a single shared library, if distributed, then in a single zip file, with both package names referring to the same file. (It would probably make sense to restrict cyclic dependencies to packages stemming from the same repository.)
No no no! This going severely in the wrong direction. Too much magic and this is also not the only problem with cyclic dependencies. Patching like this will open up more holes and cause more and more special cases to be added (well, maybe there is an end to it somewhere).
So issues are solvable, but it is really not worth the trouble if people don't package according to their D packages on a regular basis, it would only be acceptable if this was only necessary in some weird corner cases where someone needs to stay absolutely compatible with some legacies or something. The fact, that already you want to package your software not according to your D packages, despite knowing all my great good reasons why this is a good idea, is already proving that my proposal is not going to work for a public repository despite all its nice properties :-(
Not "want", I appreciate the positive properties, but the fact that even I am still running into walls and more special cases would need to be added, plus the other mentioned issues, could just be a sign that this restriction may just not be a good idea after all. I hope that you can wake up one day and suddenly you realize how these restrictions have just restrained your life up to that point ;)
But seriously, at this point I could just repeat my previous mails about complexity, actual benefit (still nothing in sight) and judgment calls.
But if the registry could instead just tell you which namespace(s) a package occupies or vice versa, you have a very similar effect (just that the user would have too look at a namespace list instead of a package list to see if a particular namespace is already occupied).
Could be done, the thing is, with my proposal it would not have been necessary. Also to offer a reliable possibility to check for conflicts, the registry has to keep a database of all file names with information about which package in what version(s) installs it. This database could then also be used to find out what package installs a particular import and also my "easy scripting" feature would make use of it.
Well, in your case you also have to make sure that all packages adhere to the restrictions, you have to manage those :suffixes, implement all the new concepts like sub-packages first and whatnot. Just adding a list of D packages for each package record really is trivial and has the nice property that it can be done at a later point when needed for the scripting feature or when it shows that people create unwanted conflicts.
It is more work and less straight forward, but with a good infrastructure and the right tools it would not be too bad. I guess this is what computers are there for.
I totally disagree. This is far less work and much more straight forward. Try to list up all the things that are necessary to implement for your proposal. If you are careful, you'll see that there is actually a lot of work in it.
The impact on the required hardware also is just not there. The storage requirements are negligible and the expensive part of checking the actually occupied name spaces of each package also has to be done in the restricted case.
The length of the proposal gives a hint of what I mean with complexity. Even if some of it is just examples and some parts are specific to our discussion, it still contains a number of new concepts that every user has to understand on top of what is already there.
The basic concept is a one-liner: "Create a package by specifying its name, the corresponding D package in your source tree will be its contents."
If you know this you would already be set for most packages, another sentence about child packages and you are basically done. The document is long, because I am going quite a bit into details, including sample package.json files and because I am trying to prove my point, explaining why I do that and why I think it is a good idea. But ok I am biased, if it seemed to be complex to me, I would have dropped it before writing it even down.
(I'll repeat my previous answer in response to your length argument: "Even if some of it is just examples and some parts are specific to our discussion, it still contains a number of new concepts that every user has to understand on top of what is already there.")
...and then you would have to start explaining the :slots and how the default is dealt with, reason about how cyclic dependencies are resolved with that special case, and start explaining how these help to adapt existing structures to the the seemingly simple core concept.
It is simple, the core concept, it's fitting things into a model that they weren't made for that makes things complex.
I really would prefer such a system, where there is a clean relationship between package and name space, too. But at this point I would consider the issues that it creates plus the still unknown benefit as more serious. The fact that we haven't seen an existing system that works like this is another sign of warning.
But I think that just storing a list of occupied name spaces for each package in the registry will lead to nearly the same practical result even without the restriction, so things should not be much worse.
Except that we would need to store a list of all modules not only namespaces, as packages are no longer restricted to a particular namespace.
Well, depending on the use case that may be the case, or may be not (you can only consider actual module clashes as a conflict, or you can already count package clashes as conflicts). Anyway, I fail to see the problem, even when capturing all modules.
I have to think a bit more about the consequences of not implementing my proposal, but with the right infrastructure and tools available, most issues should be solvable. E.g. having an IDE showing me the containing package name when I hover over an import line, having a commit hook that calls dub with some parameter that checks for conflicts with the registry, ...
Sorry, but that's a totally unrealistic case you make up there. Please, show me where such conflicts happen in reality and we can talk about it, but constructing cases like this is just... after all we have concrete issues with the restricted case but still not one concrete example of issues with the unrestricted case (and there is a sheer unlimited set of examples in the world).
People will still usually adhere to only one root package per package manager package - it should also still be the recommendation to name the D package after it's root package. And if some maniac decides to place his modules all over the global name space, surely the library will not be used and no one will ever notice the conflicts, starting to look for per module for conflicts is really over the top, IMO.
Just let me say it one more time, that this all wasn't necessary if only .... :-) Ok, I had to do it, it is hard giving up a baby.
I hear you, I used to see that clean package tree right before my eyes :)
...but then reality came in and destroyed everything ;)
I think a good analogy may be D vs. Lisp. Everything is so much cleaner when restricting everything to pure functions and that pure syntax, but at some point you realize that for certain things that's really just a burden and that the restriction may not be modeling reality sufficiently.
(Off topic: Did you send any mail today or yesterday by chance? I'm asking because my server had a harddrive failure after a power outage and I had to use a one day old backup)
No, nothing. :-)