RejectedSoftware Forums

On Tue, 12 Mar 2013 17:40:15 GMT, Robert wrote:

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.

Counting package clashes as conflicts does not work. Think of "org.eclipse.swt", most certainly another package should be allowed to use the "org" package or "org.eclipse" or even "org.eclipse.swt.something.not.in.the.base.dwt.package". Not even restricting the check to leaf packages (packages containing only modules) would be ok in all cases, if we think of C libraries that are made available via a single D module. But I agree, having to capture all modules is no real problem.

You are right, modules in the root package are certainly a problem. Also the app.d file would have to be taken out of the equation.

But maybe just counting packages with actual modules + top level modules would work. I just try to get in that direction because I think that detecting just module conflicts is a bit too relaxed and it would be good to come as close as possible to the restricted system in that regard (without introducing child packages, which could of course still be done, even if just for different reasons).

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).

I don't exactly know what you are referring to? To the commit hook thing? I am just saying that one can set up something like that, if he wants to be on the safe side. But never mind, it is quite possible that I am taking this conflict stuff a bit to serious. If you refer to the first sentence about consequences, I was not thinking about conflicts in this case, but rather whether my original goals for a package manager can still be met. "Consequences" might have been a bit of a too hard word, what I wanted to say was: "I have to think everything through again on top of the changed semantics".

I think I got your sentence mixed up a bit. Rereading it, I really don't know what I was talking about exactly and need to apologize for the slightly rude tone. I just think the commit hook is not any more or less needed than for the restricted case - just that the restricted case could just check the package name instead + verify locally that no forbidden name space is used.

Sorry, I can observe myself loosing track of the message while still reading it sometimes as my head is spinning with loads of other things (things like a HDD crash of my mail server didn't help there either). I severely need to get some things done to get my head free...

On Tue, 12 Mar 2013 20:49:18 GMT, Robert wrote:

You are right, modules in the root package are certainly a problem. Also the app.d file would have to be taken out of the equation.

There should definitely be no warning about the app.d file, maybe just being explicit on what to put into the import path is enough? (See below)

But maybe just counting packages with actual modules + top level modules would work. I just try to get in that direction because I think that detecting just module conflicts is a bit too relaxed and it would be good to come as close as possible to the restricted system in that regard (without introducing child packages, which could of course still be done, even if just for different reasons).

Ok, I'll think about it. The problem is just, that the moment you go looser than the module level, it is very much dependent on how things are organized, for detecting what is ok and what not. That is why I introduced the child packages concept. My current thinking is, that you were probably right and we should rely on people being smart and that packages of "dumb" developers would not be used any way. Meaning it would be enough to provide a way of seeing which namespaces are already claimed by what packages and issuing a warning if you really happen to accidently introduce the exact same module as someone else did already.

You are right. The good thing is that with only warnings (or even just an informational query in the registry) instead of errors, that we can always make the rules stricter (or looser) without breaking anything. So we can lean back and observe how things will look in practice before deciding on concrete improvements.

I think I got your sentence mixed up a bit. Rereading it, I really don't know what I was talking about exactly and need to apologize for the slightly rude tone. I just think the commit hook is not any more or less needed than for the restricted case - just that the restricted case could just check the package name instead + verify locally that no forbidden name space is used.

Actually the proposal was a bit different. There was no need to verify locally, instead any D package found, named like the package name, would just be put into a separate import directory, which is then added to the -I paths, instead of the source directory itself (solving the issue with app.d and other not to be exported files). In fact something like that might still be a good idea, only that now it would have to be specified explicitly what packages should be put in the import directory. We might also need this for supporting multiple packages from a single repository. The beauty of the proposal was just, that no additional configuration was necessary, as the package name already included all the needed information (in the simple case, that the library is pure D), but adding something like "exportedPackages"=["vibe"] to the package.json would do the trick too. If no "exportedPackages" is given, dub could just continue to export the whole source tree, for both backwards compatibility and keeping configurations of trivial packages simple.

I see, I missed that. It could be a little problematic with IDEs, although doable. But let's just see how things turn out over the coming months and then we can decide which additional features or checks we really need. I'd say we document the recommendation to use a single root package with the same name as the package manager package (we really need a unique name for those ;)) in a prominent place and then see how well reality fits that recommendation. If issues crop up, we put additional measures in place (only warnings, never errors) and if all packages get along nicely, we could as well stop with the global package tree database (btw. it's really nice to have that because then we can finally take some objective statistics about the problem domain :)).

Sorry, I can observe myself loosing track of the message while still reading it sometimes as my head is spinning with loads of other things (things like a HDD crash of my mail server didn't help there either). I severely need to get some things done to get my head free...

I understand, to be honest I am pretty amazed on how many things you seem to handle at the same time. vibe, dub, newsgroup/forum activity, bug fixing, user support, ... and those are only the ones that are publicly visible. So no problem at all, if you don't answer for few days because you have more important things to do, I would not mind either.

It's just always tempting to continue the discussion, as it is actually quite a bit more interesting than some of the other (more) important things ;) But well, we'll be doing a small "project vacation" next week to dedicate a block of time purely for one or two topics to get them off the table. It that turns out well, it will make things much more comfortable again (improving automation is one of the topics and that will help to save a big chunk of regular amounts of work).

I see, I missed that. It could be a little problematic with IDEs, although doable.

How come? The code would only be also made available in an import directory, which is used for -I.

But let's just see how things turn out over the coming months and then we can decide which additional features or checks we really need. I'd say we document the recommendation to use a single root package with the same name as the package manager package (we really need a unique name for those ;)) in a prominent place and then see how well reality fits that recommendation.

I'd love that.

If issues crop up, we put additional measures in place (only warnings, never errors) and if all packages get along nicely, we could as well stop with the global package tree database (btw. it's really nice to have that because then we can finally take some objective statistics about the problem domain :)).

I think having such a tree available is always a good idea, except all packages adhered to the D package = package rule, but in this case we could as well have implemented my proposal ;-) Of course this tree could be factored out onto a different server and would not have to be part of the registry (also any automatic conflict check could be dropped, if they never seem to happen). But having a reliable way to determine what name spaces are in use seems to be valuable, also mapping files to packages and vice versa is a functionality that comes in handy at times.

It's just always tempting to continue the discussion, as it is actually quite a bit more interesting than some of the other (more) important things ;) But well, we'll be doing a small "project vacation" next week to dedicate a block of time purely for one or two topics to get them off the table. It that turns out well, it will make things much more comfortable again (improving automation is one of the topics and that will help to save a big chunk of regular amounts of work).

I know what you mean, I should be learning now and not discussing stuff I care about on the internet ;-)

Best regards,
Robert

Okay what I meant with overriding was more in cases where you have a
layout.dt that is extended by another template. In a derived project you
then want to use a different layout.dt. This is out of reach of any
object oriented features or whatever means.

Ah, I see the extends syntax is the problem. :-) A not too bad solution would probably be to just call render functions (instead of defining blocks and extending it) in the layout.dt indirectly via delegates passed to the renderLayout method. I think I'll rewrite my current project this way and see how it works out. (The extends syntax did not scale very well for me anyway)

It would look something like this:
D code:
void renderLayout(HttpServerRequest req, HttpServerResponse res, RenderFunc contents, RenderFunc menu) {
mixin(renderDietFileMixin("project.layout.dt", res.bodyWriter));
}

project.layout.dt:

...
#menu

- menu(req, res);

#contents

- contents(req, res);

Now if it weren't for staying compatible with Jade I would simply extend
the Diet template syntax with explicit parameter declarations so that
proper type checking can be done at the call site (and possibly
automatically generating a proper function or another alternative kind
of interface).

I am actually quite fine with doing this explicitly, having vibe generate methods from a signature definition would probably not gain much in terms of code to write, also currently you have the documentation/interface together with the rest of the code.

Best regards,
Robert