M-hrjet has quit [Read error: Connection reset by peer]
dtz has quit [Read error: Connection reset by peer]
katafrakt[m] has quit [Read error: Connection reset by peer]
irx[m] has joined #ponylang
dtz has joined #ponylang
M-hrjet has joined #ponylang
mindB has joined #ponylang
srenatus[m] has joined #ponylang
katafrakt[m] has joined #ponylang
ada[m] has joined #ponylang
Matthias247 has joined #ponylang
endformationage has joined #ponylang
vaninwagen has joined #ponylang
vaninwagen has quit [Read error: Connection reset by peer]
_andre has quit [Quit: leaving]
inv2004 has joined #ponylang
inv2004 has quit [Client Quit]
Matthias247 has quit [Read error: Connection reset by peer]
<cquinn>
Hey @jemc, is the 'subdir' feature of pony-stable's github-dep used anywhere? It seems like an unneeded complication, and inconsistent with the local-git dep.
<cquinn>
ah, ok. He should have added it to the local-git deps type too for pony-stable. Another approach that I thought of is to have the project/bundle declare its package base subdir. That would be more self-contained
<cquinn>
but also assume that we're all using the same tool
<jemc>
yeah, I agree declaring it in the package is probably a better overall approach - pony-stable doesn't support reading any info from the package, but it sounds like the tool you're designing will
<cquinn>
or another way is to follow Go's direction and declare that Pony libraries must have their packages at repo root, and we can include the 'subdir' option as a temporary workaround while old repos get fixed up
<cquinn>
that might be better in the long run to keep things simpler.
<jemc>
eh, I'm not a big fan of having source code in the root directory of your repository in any language
<jemc>
so if that were required, I probably wouldn't want to adopt this tool :P
<jemc>
however, I think I'd be fine with the limitation that a repo is used to host just one package (with any other packages being subpackages of it)
<jemc>
so if you kept the subdir option around, that would be fine
<cquinn>
well, the source itself in my example wouldn't be at the root of the repo, but the package names would be based there.
<cquinn>
and that would likely be where the project.json would live.
<cquinn>
but in the Go world, small libraries are often just source right there at the root of the repo. it works out really well.
<cquinn>
I think for pony, though, if we had repo == project == bundle, then the packages would be in the subdirs under the repo root.
<cquinn>
But I'll leave the subdir in for now, it fits into the model ok and we can talk about deprecating it later.
g00s has joined #ponylang
<jemc>
okay, well I'm personally fine with having my package subdirectory living in the root directory of the repo, not needing the subdir option if the *repo* represents a *bundle* of packages
<jemc>
SeanTAllen wasn't, which is why he filed that PR, but I can let him speak for himself
<jemc>
however, if you wanted to move to the model of having *repo* represent a single *package* instead of a *bundle* of packages, I'd want to have the subdir option
<jemc>
since I just don't like having my main source code at the top level repo, mixed in with the `CONTRIBUTING.md` and `Dockerfile` and `Makefile` and whatever else
<jemc>
just because the Go folks don't like to organize their crap doesn't mean we all should live like wild animals :P
<jemc>
of course I'm being a bit flippant, and I don't mean to disparage any individual who wants to structure their repositories in such a way - I'm just trying to playfully express that I think it's a bad practice to encourage / require
<cquinn>
I am pretty sure that we'll want to allow more than one package per repo, but we can probably assume that the packages will all share a common root. Whether or not that package root must always be the repo root is something we can discuss
<cquinn>
I agree that the source in the repo root won't work as well for Pony
<jemc>
I'm not actually 100% certain about this - I'd be okay with requiring that a repo represents a single package, which may have subpackages
<cquinn>
then I think you'd have to extract the package name from the tail of the repo name, which might be too tough of a requirement
<cquinn>
it seems easier and more flexible to say that a repo contains one bundle or project, which in turn contains one or more packages below a single base dir
<jemc>
yeah, that's the main reason pony-stable allows multiple packages per repo - just because in the technical circumstance, it was easier to say repo==bundle than repo==package
<cquinn>
I guess that PONYPATH part is an implementation detail, but the model is simple and sound.
<cquinn>
yup
<jemc>
I was just saying that if your tool is doing more (like a symlink farm), you may want to reconsider
<cquinn>
I will do the symlink farm as a second phase, mostly for optimization I think.
<cquinn>
I can't see how making the repo==package assumption simplifies anything, so I think I'll stick with repo==bundle
<jemc>
I think it might simplify some things about the repo describing itself, since it only has to describe one package instead of many - but that may not make a practical difference, I'm not recalling the details of the design at the moment
<SeanTAllen>
cquinn: are you saying we need to fork Stable?
<cquinn>
I am working on a newer superset of Stable
<SeanTAllen>
that isnt really an answer though
<cquinn>
This is what I has started on a long time ago and ended up doing the cli package to help out building tools
<SeanTAllen>
you can remove it, but we'll end up forking
<cquinn>
forking what and why?
<cquinn>
oh, you mean the subdir option?
<SeanTAllen>
yes
<cquinn>
I will leave it in if people really want it
<SeanTAllen>
i see no reason to remove it
<SeanTAllen>
im not sure after reading this what the problem with it is
<cquinn>
I think we should have a standard way to organize Pony libraries
<cquinn>
I saw that the local-git option in Stable did not provide the subdir option, so I wasn't sure what the real use-case was for it.
<SeanTAllen>
so
<cquinn>
but maybe that was just an oversight
<SeanTAllen>
subdir was added because without it
<SeanTAllen>
local git?
<SeanTAllen>
o that
<cquinn>
that is another deps form that Stable supports
<SeanTAllen>
yeah i didnt add it to that because we never use it
<SeanTAllen>
so it didnt occur
<SeanTAllen>
its nice to say "pony libraries should be organized in a particular way"
<SeanTAllen>
but then if someone doesn't
<SeanTAllen>
well you are out of lucj
<SeanTAllen>
so you cant use stable with it because someone didnt "do it the stable way"?
<SeanTAllen>
and if people decide to use a maven plugin (someone has done that)
<SeanTAllen>
and they organize things differently?
<cquinn>
who is out of luck? If the Pony community agrees that Pony libraries should be shares a certain way, then anybody that wants to share should follow that way
<SeanTAllen>
or package manager why?
<SeanTAllen>
sorry
<SeanTAllen>
im not at all in favor of this idea
<cquinn>
but I see that where we are now, it makes more sense for the package manager to be flexible and handle what's out there
<SeanTAllen>
i fail to see what the value is in removing the option
<cquinn>
in the Go world, the organizing standard came before the package manager
<SeanTAllen>
im not sure how that is germane to this conversation
<SeanTAllen>
can you explain?
<cquinn>
I'm no longer advocating for removing the option. I am just trying to come up with a solid package sharing and managing model for Pony that is flexible but not overly complicated
<cquinn>
so I will leave the option in, it is easy to support
<SeanTAllen>
if stable was "the option" i think it would make sense
<SeanTAllen>
as it is, there is no consensus on a package manager
<SeanTAllen>
stable doesn't even work on windows right now so...
<cquinn>
but it does mean that in order to use someone's Pony library you have to go figure out where their packages are rooted
<SeanTAllen>
i dont agree with that.
<SeanTAllen>
we can say "this is how you make it work with stable"
<SeanTAllen>
and then stable can work potentially other methods
<cquinn>
ah, true. But I would like to address the package manager standard and fulfill that RFC I started commenting on
<cquinn>
you mean say that in the project's README?
<SeanTAllen>
sorry, i dont follow
<cquinn>
lol. two threads at once.
<cquinn>
we can say "this is how you make it work with stable"
<cquinn>
I was referring to this^ when I mentioned README.
<SeanTAllen>
what README?
<SeanTAllen>
to clarifiy what i meant
<SeanTAllen>
stable can and should include documentation on how to make your package easy to work with stable
<cquinn>
if there isn't a standard layout or a standard metadata file for a project, then there has to be some human readable documentation for the project that explains how to use it
<SeanTAllen>
then if people adopt that, great
<cquinn>
ok, I think we agree on that
<SeanTAllen>
i think we are talking past each other
<cquinn>
I am hoping we can come up with something a little more structured to make things automatic for people
<cquinn>
but we can start flexible and refine from that
<SeanTAllen>
do you believe i dont want that?
<cquinn>
I am not sure. :)
<SeanTAllen>
let me try again
<SeanTAllen>
there is no standard package manager
<SeanTAllen>
folks can do libraries and package however they want
<SeanTAllen>
stable should have the flexibility to work with those libraries
<cquinn>
I agree with all that ^
<SeanTAllen>
stable should advertise to library writers how to make their packages conform to what is "normal" to work with stable
<SeanTAllen>
if stable becomes the standard in the community