AFAIR there was proposal of a "future" meta package for introducing new modules with time to adapt, similar to how it is done in few other languages.

On Wed, 2013-02-06 at 08:56 +0100, Don wrote:
> Eg, are there entire top-level branches which are obsolete? How many stupid names are there (eg, "std.algorithm2") which were

Well in order to avoid such "stupid" names, I think it would be a good idea to keep the standard library small. Include only the things that are important to be "standard" in order to ensure interoperability between libraries.

Instead we should offer a central place for D libraries, like CPAN for perl or http://pypi.python.org/pypi for python.

The benefits:
- The base installation stays small, which might be important for
everything that is not a PC.
- Versioning is easier, because every library can exist in multiple
versions, and every project can choose to which version it wants to
link. (For backwards compatiblity) -> No stupid names, if the libraries
are small, simply deprecate the complete library.



-> In fact such a central place is already on my todo list. I have the idea of creating an infrastructure, where you can easily write D scripts, which may import arbitrary libraries from the repository. A tool like rdmd would then notice that the libraries are not installed locally, so it does install them before running the script. (I think of integration with http://openbuildservice.org/ for Linux based systems and some custom installer for Windows.)

-> This way we would have a really convenient way for scripting in D and
it would be easy to toy around with an idea, before creating an actual
project.
-> So instead of creating a single monster standard library, just offer
a central place for D libraries and automatic dependency management.

I hope that I find the time soon to implement such a thing, but it will be a huge amount of work and maybe this is the right occasion to ask, whether anyone else thinks this would be a good idea.

Just some of my recent thoughts.

Best regards,

Robert

On 2013-02-06 13:02, Robert wrote:
> On Wed, 2013-02-06 at 08:56 +0100, Don wrote:
>> Eg, are there entire top-level branches which are obsolete? How
>> many stupid names are there (eg, "std.algorithm2") which were
>
> Well in order to avoid such "stupid" names, I think it would be a good
> idea to keep the standard library small. Include only the things that
> are important to be "standard" in order to ensure interoperability
> between libraries.
>
> Instead we should offer a central place for D libraries, like CPAN for
> perl or http://pypi.python.org/pypi for python.

Here you go:

https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D

I will replace the Ruby code with D.

-- 
/Jacob Carlborg

On 2/6/13 8:42 AM, Jacob Carlborg wrote:
> On 2013-02-06 13:02, Robert wrote:
>> On Wed, 2013-02-06 at 08:56 +0100, Don wrote:
>>> Eg, are there entire top-level branches which are obsolete? How
>>> many stupid names are there (eg, "std.algorithm2") which were
>>
>> Well in order to avoid such "stupid" names, I think it would be a good
>> idea to keep the standard library small. Include only the things that
>> are important to be "standard" in order to ensure interoperability
>> between libraries.
>>
>> Instead we should offer a central place for D libraries, like CPAN for
>> perl or http://pypi.python.org/pypi for python.
>
> Here you go:
>
> https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
>
> I will replace the Ruby code with D.

That's awesome. I skimmed the docs and the capabilities are pretty much what I'd expect. We should push for integrating Orbit in the standard distro. That entails a formal proposal, community review and voting etc. etc.

One question - since you mention replacing Ruby with D, I'm thinking it may be a good opportunity to just use D syntax everywhere. The arguments have been hashed already - a D user is supposed to know of all syntaxes that of D itself etc.

As an example I was looking at https://github.com/jacob-carlborg/orbit/wiki/orbfile which has:

orb "dwt", "0.5.3" # specifies an exact version
orb "sqlite" # uses the latest version
orb "orange", "> 0.0.1" # uses any version greater than "0.0.1", basically any comparison operator is allowed here
orb "derelict", "~> 0.3.4" # uses any version above "0.3.4" that is "0.x.y", i.e. won't use any "1.x.y"     version

Nice enough but there's no shame about

orb("dwt", "0.5.3"); // specifies an exact version
orb("sqlite"); // uses the latest version
orb("orange", "> 0.0.1"); // uses any version greater than "0.0.1", basically any comparison operator is allowed here
orb("derelict", "~> 0.3.4"); // uses any version above "0.3.4" that is "0.x.y", i.e. won't use any "1.x.y"     version

The alternative orbspec https://github.com/jacob-carlborg/orbit/wiki/orbspec%20specification also has its own syntax:

# orange.orbspec
# name "orange" # inferred from the name of the orbspec
version "1.0.0"
author "Jacob Carlborg"
type :library
files << ["a.d", "b.di"] # an array of source files

This is in a way worse because there's a tidbit of syntax for each element. I'm thinking:

spec = "orange";
version = "1.0.0";
author = "Jacob Carlborg";
type = "library";
files = ["a.d", "b.di"]; // an array of source files

This code can be imported into an environment that has the appropriate definitions.

Hash table literals may also be also very useful.

Thoughts?


Andrei

On 02/06/2013 08:56 AM, Don wrote:
> In the "Implementing Half Floats in D" thread, we seemed to have reached a
> consensus on two important points:
> (a) Phobos should have a broad scope (rather than being small like the C
> standard library).
> (b) The current flat structure of Phobos (every module in the root) does not
> scale to hundreds of modules.

Possibly naive question -- assuming that one has a package of multiple modules, how does one go about importing the whole package?  Seems relevant if Phobos is to become nested.

On Wed, 2013-02-06 at 14:42 +0100, Jacob Carlborg wrote:
> Here you go:
> 
> https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D

:-) That is pretty much what I had in mind! Awesome! I would love to help with this. I would start with some writing down of my ideas and concepts I have in mind, if you are interested? If you are, where should we discuss such things? On this mailing list?
> 
> I will replace the Ruby code with D.
As the ultimate goal of my idea was to establish D as a compiled language with all/most of the benefits of interpreted languages, it would seem strange if the tool that made this possible was not written in D. It would suggest that this was not possible in the first place. So I think this is a good idea.

Concise definitions could be made possible, either by importing stuff in an appropriate environment as Andrei suggested or if needed even via a DSL, with string mixin's. So I think D already offers all we need, for good concise configuration files?


Best regards,

Robert

Joseph Rushton Wakeling:

> Possibly naive question -- assuming that one has a package of multiple modules, how does one go about importing the whole package?  Seems relevant if Phobos is to become nested.

I think implementing this:
http://d.puremagic.com/issues/show_bug.cgi?id=3603

Bye,
bearophile

On 2013-02-06 15:03, Andrei Alexandrescu wrote:

> That's awesome. I skimmed the docs and the capabilities are pretty much
> what I'd expect. We should push for integrating Orbit in the standard
> distro. That entails a formal proposal, community review and voting etc.
> etc.

This tool has a couple of dependencies on my own libraries (available of course) and Tango. I'm not feeling so enthusiastic to remove these dependencies.

https://github.com/jacob-carlborg/dstack
https://github.com/jacob-carlborg/mambo

> One question - since you mention replacing Ruby with D, I'm thinking it
> may be a good opportunity to just use D syntax everywhere. The arguments
> have been hashed already - a D user is supposed to know of all syntaxes
> that of D itself etc.

That was what I was referring to.

> Thoughts?

I was thinking having basically the same syntax. One syntax I'm not sure what to do about is the hash literal syntax Ruby uses.

orb "dwt", git: "git://github.com/jacob-carlborg/dwt.git"

https://github.com/jacob-carlborg/orbit/wiki/Integration

The above could be translated to:

orb("dwt", ["git" : "git://github.com/jacob-carlborg/dwt.git");

That doesn't look very nice.

Also I might need to be able pass values of different types in the same hash. Sure, Variant can be used in that case but that would look even more uglier.

-- 
/Jacob Carlborg

06-Feb-2013 17:42, Jacob Carlborg пишет:
> On 2013-02-06 13:02, Robert wrote:
>> On Wed, 2013-02-06 at 08:56 +0100, Don wrote:
>>> Eg, are there entire top-level branches which are obsolete? How
>>> many stupid names are there (eg, "std.algorithm2") which were
>>
>> Well in order to avoid such "stupid" names, I think it would be a good
>> idea to keep the standard library small. Include only the things that
>> are important to be "standard" in order to ensure interoperability
>> between libraries.
>>
>> Instead we should offer a central place for D libraries, like CPAN for
>> perl or http://pypi.python.org/pypi for python.
>
> Here you go:
>
> https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
>
I've been wondering what happened to it, looks fine I think.

> I will replace the Ruby code with D.

Great!

-- 
Dmitry Olshansky

On 2/6/13 11:09 AM, Jacob Carlborg wrote:
> On 2013-02-06 15:03, Andrei Alexandrescu wrote:
>
>> That's awesome. I skimmed the docs and the capabilities are pretty much
>> what I'd expect. We should push for integrating Orbit in the standard
>> distro. That entails a formal proposal, community review and voting etc.
>> etc.
>
> This tool has a couple of dependencies on my own libraries (available of
> course) and Tango. I'm not feeling so enthusiastic to remove these
> dependencies.
>
> https://github.com/jacob-carlborg/dstack
> https://github.com/jacob-carlborg/mambo

I understand. The way I see this is as an motivation and opportunity to add the necessary functionality to Phobos. I may be uninformed, but the way I see it basic package management doesn't have to be very demanding on library functionality.

>> One question - since you mention replacing Ruby with D, I'm thinking it
>> may be a good opportunity to just use D syntax everywhere. The arguments
>> have been hashed already - a D user is supposed to know of all syntaxes
>> that of D itself etc.
>
> That was what I was referring to.
>
>> Thoughts?
>
> I was thinking having basically the same syntax. One syntax I'm not sure
> what to do about is the hash literal syntax Ruby uses.
>
> orb "dwt", git: "git://github.com/jacob-carlborg/dwt.git"
>
> https://github.com/jacob-carlborg/orbit/wiki/Integration
>
> The above could be translated to:
>
> orb("dwt", ["git" : "git://github.com/jacob-carlborg/dwt.git");
>
> That doesn't look very nice.
>
> Also I might need to be able pass values of different types in the same
> hash. Sure, Variant can be used in that case but that would look even
> more uglier.

I'd say go with strings throughout. For the package manager "compile-time" is pretty much same as "run-time" so no need for early typechecking.


Andrei