On Wednesday, 11 March 2015 at 06:56:27 UTC, Andrei Alexandrescu wrote:
> On 3/10/15 11:52 PM, Vladimir Panteleev wrote:
>> I can only urge you to consult with someone deeply involved with Vibe
>> (e.g. Sonke), as well as someone who uses Vibe and Dub heavily in
>> production, before forcing a decision.
>
> Sönke was up for it last time we communicated. This isn't forcing any decision as much as pushing things in order toward a greater goal. -- Andrei

If we want Vibe.d to keep in sync with D, isn't the easiest way to do that making it part of the standard library as etc.vibe.* or something?

On Wednesday, 11 March 2015 at 07:01:02 UTC, Meta wrote:
> On Wednesday, 11 March 2015 at 06:56:27 UTC, Andrei Alexandrescu wrote:
>> On 3/10/15 11:52 PM, Vladimir Panteleev wrote:
>>> I can only urge you to consult with someone deeply involved with Vibe
>>> (e.g. Sonke), as well as someone who uses Vibe and Dub heavily in
>>> production, before forcing a decision.
>>
>> Sönke was up for it last time we communicated. This isn't forcing any decision as much as pushing things in order toward a greater goal. -- Andrei
>
> If we want Vibe.d to keep in sync with D, isn't the easiest way to do that making it part of the standard library as etc.vibe.* or something?

Simply adding it to auto-tester would achieve the same goal without introducing awkward library paths.

On Wednesday, 11 March 2015 at 06:30:52 UTC, Andrei Alexandrescu wrote:
> On 3/10/15 10:43 PM, Vladimir Panteleev wrote:
>> Including Vibe without Dub is certainly a mistake, because
>> inter-component versioning relies on Dub.
>
> Fine, let's include dub too.

There is 1.0.0 milestone in dub GitHub repo : https://github.com/D-Programming-Language/dub/milestones/1.0.0

It includes bunch of issues created ~year ago when we first started to consider what it would take to make a somewhat stable dub release (distributing with compiler puts more pressure on stability). Sadly, no one has really worked on those which is why further dub integration has stalled. Some sort of call for arms may help.

On 2015-03-11 07:45, Andrei Alexandrescu wrote:

> Vladimir, please work with me on this. This is clearly subjective so
> it's really what you believe is good vs. what I believe is good. I want
> to make sure vibe releases are in sync and guaranteed to work with dmd,
> thus making for a perfectly smooth experience.
>
> Don't forget things like the IE icon being on the desktop or not, or the
> default search engine, or the default homepage - all are big things
> although technically alternatives were always a few seconds away.
>
> I don't have logical arguments, this could go either way. So work with
> me on this. Thanks.

How about including both Dub and vibe.d? I mean that one would _not_ need to run Dub to get vibe.d, but Dub would be available for other libraries.

-- 
/Jacob Carlborg

On 2015-03-11 07:56, Andrei Alexandrescu wrote:

> Sönke was up for it last time we communicated. This isn't forcing any
> decision as much as pushing things in order toward a greater goal. --
> Andrei

I agree with Dicebot and Vladimir that including vibe.d without Dub might cause more harm than doing good. But I don't see why we can't include both.

-- 
/Jacob Carlborg

On Wednesday, 11 March 2015 at 06:45:17 UTC, Andrei Alexandrescu wrote:
> I want to make sure vibe releases are in sync and guaranteed to work with dmd, thus making for a perfectly smooth experience.

How will bundling Vibe with D achieve that goal?

What will ACTUALLY change by bundling Vibe with D?

What happens if a regression occurs in Vibe just before a D release? Do we block the release for the sake of Vibe? What if there's no one around to fix it? We have enough problems with blocking bugs in Dub/Vibe-related components in the dlang.org repo already.

What happens if we discover a regression in Vibe after a D release? Do we make a point release just for the sake of Vibe?

What if Vibe needs to iterate faster than DMD's release cycle?

My question about Vibe API versioning still stands, what if people want to use an older Vibe with a newer DMD?

Precedent shows that Vibe and related components simply do not have a bus factor high enough to not be a liability if included with D.

I am trying to work with you here. We just have different values on what is actually important, or there is something more to this plan that I don't see, something more than just including Vibe in dmd.zip.

We do not have a strong precedent for this. The closest thing we have are things like Dustmite, which are so specialized that they don't matter in this case, and Visual D, which I'm not really sure greatly benefited from the exposure - we've covered one IDE among many, and despite moving the project under github.com/D-P-L, Rainer remains the sole maintainer. And you know the story with DDox.

What is indubitably, actually, very important, and something I'm surprised you haven't pushed for since long ago, is making it EASY to get more things. Dub absolutely must be a part of D, and not today but one or more years ago. There is now a rift in this community, between people who use code.dlang.org and its packages, and those who do not. This is not close to the Tango/Phobos split, but we cannot afford anything like this again.

Coming from a language with a package manager, and then trying to build a project with a dozen dependencies by manually cloning the repositories and making sure they are the correct version, is madness. A package manager encourages people to build many small reusable components, because the overhead of managing each component becomes very small, and this is something we really want.

From this perspective, Vibe itself is not that special. It is one big piece of the puzzle, but its value is greatly diminished in isolation.

You don't need to bring in Vibe in D itself, you need to bring in the entire ecosystem.

On 3/11/15 12:17 AM, Jacob Carlborg wrote:
> How about including both Dub and vibe.d?

That sounds good. -- Andrei

On 3/11/15 12:19 AM, Vladimir Panteleev wrote:
> On Wednesday, 11 March 2015 at 06:45:17 UTC, Andrei Alexandrescu wrote:
>> I want to make sure vibe releases are in sync and guaranteed to work
>> with dmd, thus making for a perfectly smooth experience.
>
> How will bundling Vibe with D achieve that goal?
>
> What will ACTUALLY change by bundling Vibe with D?

Many people know of D but not of vibe.

> What happens if a regression occurs in Vibe just before a D release? Do
> we block the release for the sake of Vibe?

Yes.

> What if there's no one around
> to fix it? We have enough problems with blocking bugs in
> Dub/Vibe-related components in the dlang.org repo already.

We need to rally support around it.

> What happens if we discover a regression in Vibe after a D release? Do
> we make a point release just for the sake of Vibe?

Yes.

> What if Vibe needs to iterate faster than DMD's release cycle?

A bundle deal is what it is.

> My question about Vibe API versioning still stands, what if people want
> to use an older Vibe with a newer DMD?

They can in the same way they can use an older Phobos. It's up to them to make it work.

> Precedent shows that Vibe and related components simply do not have a
> bus factor high enough to not be a liability if included with D.

There is one way to increase the bus factor. Making vibe more visible is better for vibe folks and of course for users.

> I am trying to work with you here.

It doesn't seem so to me. You find easy weaknesses in my vision and pump on them instead of working on making it stronger. That's the easy "but that business won't work, and here are the reasons why" approach. The harder part is finding ways to make it work by overcoming its weaknesses.

> We just have different values on what
> is actually important, or there is something more to this plan that I
> don't see, something more than just including Vibe in dmd.zip.
>
> We do not have a strong precedent for this.

If we continue to do what we've been doing, we'll progress at the rate we've been progressing. That's not enough.

> The closest thing we have
> are things like Dustmite, which are so specialized that they don't
> matter in this case, and Visual D, which I'm not really sure greatly
> benefited from the exposure - we've covered one IDE among many, and
> despite moving the project under github.com/D-P-L, Rainer remains the
> sole maintainer. And you know the story with DDox.

Yah, that's a bummer. Yet neither of these is as comprehensive as vibe.

> What is indubitably, actually, very important, and something I'm
> surprised you haven't pushed for since long ago, is making it EASY to
> get more things. Dub absolutely must be a part of D, and not today but
> one or more years ago. There is now a rift in this community, between
> people who use code.dlang.org and its packages, and those who do not.
> This is not close to the Tango/Phobos split, but we cannot afford
> anything like this again.

Agreed. Dub should be in.

> Coming from a language with a package manager, and then trying to build
> a project with a dozen dependencies by manually cloning the repositories
> and making sure they are the correct version, is madness. A package
> manager encourages people to build many small reusable components,
> because the overhead of managing each component becomes very small, and
> this is something we really want.
>
>  From this perspective, Vibe itself is not that special. It is one big
> piece of the puzzle, but its value is greatly diminished in isolation.
>
> You don't need to bring in Vibe in D itself, you need to bring in the
> entire ecosystem.

We must make vibe part of D.


Andrei

On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei Alexandrescu wrote:
> On 3/11/15 12:19 AM, Vladimir Panteleev wrote:
>> What will ACTUALLY change by bundling Vibe with D?
>
> Many people know of D but not of vibe.

Precedent shows that this does not work. Including Dustmite with D did not solve the issue that you have to know about Dustmite before you can even think about using it.

If you want to increase Vibe's visibility, adding a few links to dlang.org will serve this goal much better.

>> What happens if a regression occurs in Vibe just before a D release? Do
>> we block the release for the sake of Vibe?
>
> Yes.

Are you really OK with this? Is everyone OK with this?

Everyone who does not use Vibe almost certainly is not going to be OK with this.

>> What if there's no one around
>> to fix it? We have enough problems with blocking bugs in
>> Dub/Vibe-related components in the dlang.org repo already.
>
> We need to rally support around it.

Precedent shows that this does not work. Regressions have stayed unfixed up to and past prior D releases.

>> My question about Vibe API versioning still stands, what if people want
>> to use an older Vibe with a newer DMD?
>
> They can in the same way they can use an older Phobos. It's up to them to make it work.

Is everyone OK with this? I don't have enough experience with Vibe to know how important this is.

>> Precedent shows that Vibe and related components simply do not have a
>> bus factor high enough to not be a liability if included with D.
>
> There is one way to increase the bus factor. Making vibe more visible is better for vibe folks and of course for users.

Precedent shows that this does not work. Neither Dustmite nor Visual D magically got an increase in developers.

>> I am trying to work with you here.
>
> It doesn't seem so to me. You find easy weaknesses in my vision and pump on them instead of working on making it stronger. That's the easy "but that business won't work, and here are the reasons why" approach. The harder part is finding ways to make it work by overcoming its weaknesses.

No, you're saying that just because I don't agree with your immediate goal, then I'm not working with you. I indeed do not agree with your immediate goal, but I do agree with the long-term goal.

>> We do not have a strong precedent for this.
>
> If we continue to do what we've been doing, we'll progress at the rate we've been progressing. That's not enough.

This is wishful thinking. Precedent shows that this does not work. Working force is not going to materialize from thin air just because you attract more attention to it.

>> The closest thing we have
>> are things like Dustmite, which are so specialized that they don't
>> matter in this case, and Visual D, which I'm not really sure greatly
>> benefited from the exposure - we've covered one IDE among many, and
>> despite moving the project under github.com/D-P-L, Rainer remains the
>> sole maintainer. And you know the story with DDox.
>
> Yah, that's a bummer. Yet neither of these is as comprehensive as vibe.

This just means that the problem will be stronger with Vibe. Vibe is more complicated, and there will be fewer people familiar with all parts of it. Will there be enough to keep it running in pace with D?

On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei Alexandrescu wrote:
> It doesn't seem so to me. You find easy weaknesses in my vision and pump on them instead of working on making it stronger. That's the easy "but that business won't work, and here are the reasons why" approach. The harder part is finding ways to make it work by overcoming its weaknesses.

Here is a counter-proposal:

1. Add Dub to D.

2. Add a "web development" link in the sidebar, which simply links to vibed.org.

3. Add an example on the front page on how to create a simple web server. It needs to list only main.d and package.json, and the dub command line to build it. A package.json will be needed for non-trivial things anyway, so might as well get that out of the way anyway.

4. Unite the Vibe.d forum with forum.dlang.org. I should be able to do this by making forum.dlang.org connect to it via NNTP.

I think this will achieve much of your goal without the drawbacks.