RejectedSoftware Forums

Sign up

Pages: 1 2 3 4

Re: Should packages be restricted to a single name space?

That will work, just the indentation of the HTML output will be messed
up (not that anyone will care...).

-> That is true :-) It is a bit annoying when viewing the output, but not really a big deal.

But I actually like the way it is
possible to override for the extends way of doing things. No need for
delegates or classes.

Yeah, it is kind of nice. In my project I just needed to have also just the contents retrievable (not the whole page), so I had a diet file extending the layout which just called another diet function rendering the contents. Soon later I had to write a Java servelet for a course at university and there more or less the technique I just presented was used, I think something like extends is not available for Java servelets. The benefit is that your contents are independent from the layout and the layout is independent from the actual contents, which makes it easier to reuse stuff. But I haven't tried it yet with D and vibe, so I don't know how practical it really is.

Best regards,
Robert

Re: Should packages be restricted to a single name space?

Yeah, it depends if it has efficient means to list all files. I haven't seen one, but I haven't searched for it either.

:-( There seems to be no way of listing files remotely, at least I can not find anything in the API documentation. You seem to always need a locally available repository.

Re: Should packages be restricted to a single name space?

On Sat, 09 Mar 2013 20:10:12 GMT, Jonathan M Davis wrote:

Another thought. What if I had two libraries that had the same API but just had different implementations? I could then have two projects with exactly the same package hierarchy and swap one out for the other simply by changing the dub configuration file for my project (or even base it on the configuration - though depending on how dub installs stuff, that may not work). There are other ways to handle that which may be cleaner (e.g. using different version identifiers), but that might be something that someone would want to do. In particular, if a project got forked, the fork may want to keep exactly the same package layout in order to make it easy for other projects to switch over to it, whereas if they were forced to have a base package named after the project, that wouldn't work.

That's kind of like how DWT works. The public API is the same on all platforms, but it also contains an internal/private API that is platform specific.

Re: Should packages be restricted to a single name space?

On Sun, 10 Mar 2013 10:39:39 GMT, Sönke Ludwig wrote:

(e.g. I may be wrong, but I think nobody would use those org.* DWT sub-packages in isolation, but always as a whole, no point in making them all so prominent in the registry).

Some of them cannot be used on their own.

Re: Should packages be restricted to a single name space?

On Tue, 12 Mar 2013 12:58:30 GMT, Robert wrote:

It seems we already have conflicts:

https://github.com/Domain/java/tree/master/java

and

https://github.com/d-widget-toolkit/base/tree/master/src

I think people should at least be aware of such things, when uploading packages, so they can discuss whether the implementations could be merged or how they want to proceed. Having libraries depending on one implementation and others depending on the other one, seems really bad.

Maybe I have a look on how to implement some conflict detection mechanism for the registry/dub? Would such a contribution be welcome? Basically what we already discussed, the registry would need to keep track of files, contained in packages.

There won't be a conflict unless both packages are installed and used.

Re: Should packages be restricted to a single name space?

On Sat, 09 Mar 2013 12:11:07 GMT, Sönke Ludwig wrote:

So over the last days we have had a long discussion initiated by Robert Klotzner about how a package manager for D should look like. One of the controversial topics was if each package should be restricted to have all source files inside of a single D package. The idea is to allow no conflicting packages to be created, so that all public packages are guaranteed to not cause conflicts during compilation.

I think this approach has some obvious merits to it and would facilitate a very clean way of laying things out as packages. I would also happily adjust my packages to such a system. However, I still struggle with the idea because of some issues:

  1. Existing projects would often violate this constraint and would have to be restructured in one way or another. I think that this might drive some people away and some important libraries may in turn not be available as packages.

  2. It hampers forking projects or crafting alternative implementations since all modules need to be renamed first before publishing as a package. It would also mean that all packages that now depend on the forked package instead of the original need to be adjusted accordingly. This could be mitigated to some degree by meta packages that switch to different implementations conditionally, but those would also need to be maintained by someone and, if they should have a pretty name, it would imply that their existence was planned already before the first original library appeared. Furthermore it would mean that it's author would be the one who solely decides which implementations get supported.

  3. One idea was to force the name of a package to be equal to the root name space for the package (e.g. a "derelict.gl" package would only contain modules below derelict.gl). There are some precedents where the name differs, so this would be another case of 1. It also would require to rename a number of already existing packages. (As a technical detail, dots are not allowed in package names, but that can be resolved in one way or another)

  4. It would considerably increase the implementation complexity of the registry if it is supposed to be enforced reliably. It would also require more education for people who want to create packages and thus also increase the perceived complexity of the system.

  5. Orphaned packages would clutter up the available name space and some kind of manual intervention would be required to remove those packages. This may be a difficult judgement call as people might still be using those packages (except, if the replacement is supposed to be 100% compatible). Similarly, the first who gets a name space, owns it. Should someone register "derelict" or "deimos" and use it for something else, who decides what happens?

  6. The strict enforcement breaks down with multiple registries as they have no way to know which name spaces are already in use on other registries. This may not be much of an issue though, as long as there is only one main public registry.

  7. There may still be conflicts, for example for string imports or runtime resources. However, these conflicts might even be desirable (e.g. overriding of Diet templates).

How much weight each point has compared to the benefits of this approach varies a lot with personal preferences and available work force. My main concern is number 1. It would be great to get some more opionions on this, especially from people affected by 1 and also to look at how many popular projects would actually have to be restructured.

I would say that in general I think that the proposal by Robert seems too complex. I'm also thinking that Dub has a too strong connection to repositories. The way Orbit works is that only depends on a Zip file containing all files needed to build the package and a file with meta info. There's no restriction of a 1-to-1 mapping of package and repository. There can be multiple packages from a single repository and there can be a single package from multiple repositories. Orbit doesn't care where the files come from, just that only necessary files are present.

This doesn't mean that Orbit cannot use a repository as a package. It just clones the repository and builds a package out of it, just as if the files where not in a repository.

Re: Should packages be restricted to a single name space?

I would say that in general I think that the proposal by Robert seems too complex. I'm also thinking that Dub has a too strong connection to repositories. The way Orbit works is that only depends on a Zip file containing all files needed to build the package and a file with meta info. There's no restriction of a 1-to-1 mapping of package and repository. There can be multiple packages from a single repository and there can be a single package from multiple repositories. Orbit doesn't care where the files come from, just that only necessary files are present.

That connection basically exists only in the registry implementation.
Dub just downloads a zip file from there with the contents of the
package. From where that file comes is, as far as Dub is concerned,
completely irrelevant. So uploading of custom zip packages would be an
option, or adding support for (public) sub-packages in a repository one
way or another.

Also, a valid registry can just be a public folder of files (one index
file with a list of all packages and a JSON description + a zip file per
package and per version).

Re: Should packages be restricted to a single name space?

On Tue, 19 Mar 2013 07:33:29 +0100, Sönke Ludwig wrote:

That connection basically exists only in the registry implementation.
Dub just downloads a zip file from there with the contents of the
package. From where that file comes is, as far as Dub is concerned,
completely irrelevant. So uploading of custom zip packages would be an
option, or adding support for (public) sub-packages in a repository one
way or another.

Also, a valid registry can just be a public folder of files (one index
file with a list of all packages and a JSON description + a zip file per
package and per version).

Ok, I see.

Re: Should packages be restricted to a single name space?

There won't be a conflict unless both packages are installed and used.

I know that, but I think a developer should at least be aware of the fact that his package can not be used together with some other package.

Pages: 1 2 3 4