New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Directory structure re-organization #448

Closed
bhauer opened this Issue Aug 22, 2013 · 17 comments

Comments

Projects
None yet
8 participants
@bhauer
Member

bhauer commented Aug 22, 2013

With so many framework implementations (it's awe-inspiring, really), the root directory is a little unruly.

Assuming it isn't especially difficult to do so, I'd like to re-organize the root directory structure slightly:

  • /frameworks - Move all of the framework directories currently found at the root into here.
  • /config - Leave the config directory at the root.
  • /results - Leave the results directory at the root.
    • /round6
    • /round6/final - Wrk logs from the final version of Round 6
    • /round7
    • /round7/preview1 - Wrk logs from a preview 1 of Round 7
    • /round7/preview2
    • /round7/final
  • /toolset (or /harness or /scripts or whatever) - The Python, Bash, and Windows Powershell scripts.

Leaving just README.md and .gitignore files at the root.

Thoughts?

@kppullin

This comment has been minimized.

Contributor

kppullin commented Aug 22, 2013

I like it. I'll further throw out the idea of grouping items in the /frameworks directory by platform/language.

  • /frameworks/jvm
  • /frameworks/python
  • /frameworks/dotnet
  • etc
@fernandoacorreia

This comment has been minimized.

Contributor

fernandoacorreia commented Aug 22, 2013

I agree. Regarding /toolset, I was going to suggest to create a directory for installation / execution scripts. But I think we should take it a step further and subdivide the /toolset directory by category.

The Azure deployment scripts I'm working on will require a directory of their own. I can envision a similar deployment script for AWS which would create the instances and automatically setup the environment. Those two environments could share some code (what is executed after the instances are created). This common code could be used to automate deployment for other environments (e.g. Rackspace, on-premises Microsoft System Center, etc.)

There is also setup for Linux server and client, Windows server and SQL server, each with their own bootstrap and auxiliary files. It's easy to see the /toolset directory getting out of hand soon.

One attempt to organize it:

/toolset: README.md for the toolset, run-tests.py
/toolset/benchmark: benchmarker.py, framework_test.py, latest.json
/toolset/deployment/aws: AWS deployment scripts
/toolset/deployment/azure: Windows Azure deployment scripts
/toolset/deployment/common: shared deployment scripts
/toolset/setup/common: installer.py, setup_util.py, unbuffered.py
/toolset/setup/windows: installer-bootstrap.ps1, installer.ps1
/toolset/setup/sqlserver: setup-sqlserver-bootstrap.ps1, setup-sqlserver.ps1

@bhauer

This comment has been minimized.

Member

bhauer commented Aug 22, 2013

@kppullin I like that idea of grouping by platform. It would further reduce the clutter in any single directory and help people find what they are looking for.

@fernandoacorreia That plan of further organization within the toolset directory sounds great too. If you have time and interest in making the change, I'd be happy to see it. If not, we'll get to it over here when we can find some time.

Thanks!

@fernandoacorreia

This comment has been minimized.

Contributor

fernandoacorreia commented Aug 26, 2013

I've made an initial pass at restructuring the toolset directory. You can see the commit in my fork and the forked branch.

I'm currently testing the changes and they may need a few adjustments in scripts due to changed directory names.

You'll notice that the "deployment" directory seems pointless now, but it will soon receive automated deployment scripts I'm working on.

@bhauer

This comment has been minimized.

Member

bhauer commented Aug 27, 2013

Looks like great progress. Thanks again for your continued contributions, @fernandoacorreia!

@bhauer

This comment has been minimized.

Member

bhauer commented Oct 24, 2013

Updated issue description at top to include a proposed layout for the Results directory.

(Aside: I don't know how to do more than 2 levels of bullet indentation in Markdown!)

@serroba

This comment has been minimized.

serroba commented Jul 2, 2014

I like the idea, but I think there should be as well a directory for the implementation using the nake language without framework

For instance, the PHP fremework test are using as base the implementation in vanilla PHP. I think in general is a good idea to have the vanilla implementation and a place to hold the frameworks, which should as well be aggregated on base of the platform/language

@methane

This comment has been minimized.

Contributor

methane commented Jul 2, 2014

@serroba I think frameworks/php/raw or frameworks/php/vanilla is enough.

@serroba

This comment has been minimized.

serroba commented Jul 3, 2014

@methane that's as well a good idea.

Actually the name raw is used across the project when using the DB against ORM or Raw.

I don't mind the name, but I mind that should be easy to read/understand for anyone. What I would like is that someone that is landing in the project, can start to write code quick and not to have to spend long time just trying to understand the tree and how things are organized.

@bhauer

This comment has been minimized.

Member

bhauer commented Jul 3, 2014

About "raw," @serroba makes a good point: I'd like to avoid using that term for anything other than the means of database connectivity to reduce confusion. To-date, we have used the word "plain" to refer to a platform without a framework. E.g., plain PHP, plain Servlet, plain Netty. But I would be okay with "vanilla" as @methane suggested as well.

However, I would prefer to organize the /frameworks directory by language first, and framework/platform second. Platform is a looser concept than language, and the precise definition of platform varies by language.

So for example, I would like something like the following:

/frameworks/php/plain   (or /frameworks/php/vanilla)
/frameworks/php/laravel
/frameworks/java/servlet
/frameworks/java/netty
/frameworks/java/spark
/frameworks/java/wicket

I think this would be awesome. Thoughts?

@serroba

This comment has been minimized.

serroba commented Jul 3, 2014

Although I like the most the term vanilla, I still remember a couple of
years ago that I didn't understand what they were talking with the vanilla
'preposition'. As I no native English speaker I remember that I needed the
explanation why vanilla.

Plain on the other hand is self explanatory. So thinking in the non native
English speakers I think I would vote for plain instead of vanilla.
On Jul 4, 2014 1:30 AM, "Brian Hauer" notifications@github.com wrote:

About "raw," @serroba https://github.com/serroba makes a good point:
I'd like to avoid using that term for anything other than the means of
database connectivity to reduce confusion. To-date, we have used the word
"plain" to refer to a platform without a framework. E.g., plain PHP, plain
Servlet, plain Netty. But I would be okay with "vanilla" as @methane
https://github.com/methane suggested as well.

However, I would prefer to organize the /frameworks directory by language
first, and framework/platform second. Platform is a looser concept than
language, and the precise definition of platform varies by language.

So for example, I would like something like the following:

/frameworks/php/plain (or /frameworks/php/vanilla)
/frameworks/php/laravel
/frameworks/java/servlet
/frameworks/java/netty
/frameworks/java/spark
/frameworks/java/wicket

I think this would be awesome. Thoughts?


Reply to this email directly or view it on GitHub
#448 (comment)
.

hamiltont added a commit to hamiltont/FrameworkBenchmarks that referenced this issue Jul 6, 2014

Enable framework-specific install directories and environment
This commit is my proof-of concept, only the 'go' test works right now.
You can look at go/ to see the changes required on a per-framework
basis - essentially I've modified go/setup.py to move the declaration
of the environment into go/bash_profile.sh

Each framework now gets a personal <framework>/installs directory, and
can declare any needed environment variables in
<framework>/bash_profile.sh, such as modifications to the PATH.

The FwBm code now provides an FWROOT environment variable to
*all* shell scripts (instead of ~/Frameworks being assumed).
Also, an IROOT environment variable is provided to any framework-specific
files (e.g. install.sh and bash_profile.sh) for the location of the install directory
for that framework. See go/bash_profile.sh to see me using both IROOT and
FWROOT.

By using IROOT, the strategy for installation is still controlled by python code and
the frameworks just reference IROOT and FWROOT in their scripts. These
variables are a nice step towards solving TechEmpower#448

The new function replace_environ in setup_util.py goes a long way towards
addressing TechEmpower#899 - as you can see I've removed all the changes to the ~/.bash_profile
from prerequisites.sh (and this commit serves as proof that everything still works) and
most of the changes from config/benchmark_profile

hamiltont added a commit to hamiltont/FrameworkBenchmarks that referenced this issue Jul 7, 2014

Enable framework-specific install directories and environment
This commit is my proof-of concept, only the 'go' test works right now.
You can look at go/ to see the changes required on a per-framework
basis - essentially I've modified go/setup.py to move the declaration
of the environment into go/bash_profile.sh

Each framework now gets a personal <framework>/installs directory, and
can declare any needed environment variables in
<framework>/bash_profile.sh, such as modifications to the PATH.

The FwBm code now provides an FWROOT environment variable to
*all* shell scripts (instead of ~/Frameworks being assumed).
Also, an IROOT environment variable is provided to any framework-specific
files (e.g. install.sh and bash_profile.sh) for the location of the install directory
for that framework. See go/bash_profile.sh to see me using both IROOT and
FWROOT.

By using IROOT, the strategy for installation is still controlled by python code and
the frameworks just reference IROOT and FWROOT in their scripts. These
variables are a nice step towards solving TechEmpower#448

The new function replace_environ in setup_util.py goes a long way towards
addressing TechEmpower#899 - as you can see I've removed all the changes to the ~/.bash_profile
from prerequisites.sh (and this commit serves as proof that everything still works) and
most of the changes from config/benchmark_profile

hamiltont added a commit to hamiltont/FrameworkBenchmarks that referenced this issue Jul 7, 2014

Enable framework-specific install directories and environment
This commit is my proof-of concept, only the 'go' test works right now.
You can look at go/ to see the changes required on a per-framework
basis - essentially I've modified go/setup.py to move the declaration
of the environment into go/bash_profile.sh

Each framework now gets a personal <framework>/installs directory, and
can declare any needed environment variables in
<framework>/bash_profile.sh, such as modifications to the PATH.

The FwBm code now provides an FWROOT environment variable to
*all* shell scripts (instead of ~/Frameworks being assumed).
Also, an IROOT environment variable is provided to any framework-specific
files (e.g. install.sh and bash_profile.sh) for the location of the install directory
for that framework. See go/bash_profile.sh to see me using both IROOT and
FWROOT.

By using IROOT, the strategy for installation is still controlled by python code and
the frameworks just reference IROOT and FWROOT in their scripts. These
variables are a nice step towards solving TechEmpower#448

The new function replace_environ in setup_util.py goes a long way towards
addressing TechEmpower#899 - as you can see I've removed all the changes to the ~/.bash_profile
from prerequisites.sh (and this commit serves as proof that everything still works) and
most of the changes from config/benchmark_profile

hamiltont added a commit to hamiltont/FrameworkBenchmarks that referenced this issue Jul 8, 2014

Enable framework-specific install directories and environment
This commit is my proof-of concept, only the 'go' test works right now.
You can look at go/ to see the changes required on a per-framework
basis - essentially I've modified go/setup.py to move the declaration
of the environment into go/bash_profile.sh

Each framework now gets a personal <framework>/installs directory, and
can declare any needed environment variables in
<framework>/bash_profile.sh, such as modifications to the PATH.

The FwBm code now provides an FWROOT environment variable to
*all* shell scripts (instead of ~/Frameworks being assumed).
Also, an IROOT environment variable is provided to any framework-specific
files (e.g. install.sh and bash_profile.sh) for the location of the install directory
for that framework. See go/bash_profile.sh to see me using both IROOT and
FWROOT.

By using IROOT, the strategy for installation is still controlled by python code and
the frameworks just reference IROOT and FWROOT in their scripts. These
variables are a nice step towards solving TechEmpower#448

The new function replace_environ in setup_util.py goes a long way towards
addressing TechEmpower#899 - as you can see I've removed all the changes to the ~/.bash_profile
from prerequisites.sh (and this commit serves as proof that everything still works) and
most of the changes from config/benchmark_profile

hamiltont added a commit to hamiltont/FrameworkBenchmarks that referenced this issue Jul 8, 2014

Enable framework-specific install directories and environment
This commit is my proof-of concept, only the 'go' test works right now.
You can look at go/ to see the changes required on a per-framework
basis - essentially I've modified go/setup.py to move the declaration
of the environment into go/bash_profile.sh

Each framework now gets a personal <framework>/installs directory, and
can declare any needed environment variables in
<framework>/bash_profile.sh, such as modifications to the PATH.

The FwBm code now provides an FWROOT environment variable to
*all* shell scripts (instead of ~/Frameworks being assumed).
Also, an IROOT environment variable is provided to any framework-specific
files (e.g. install.sh and bash_profile.sh) for the location of the install directory
for that framework. See go/bash_profile.sh to see me using both IROOT and
FWROOT.

By using IROOT, the strategy for installation is still controlled by python code and
the frameworks just reference IROOT and FWROOT in their scripts. These
variables are a nice step towards solving TechEmpower#448

The new function replace_environ in setup_util.py goes a long way towards
addressing TechEmpower#899 - as you can see I've removed all the changes to the ~/.bash_profile
from prerequisites.sh (and this commit serves as proof that everything still works) and
most of the changes from config/benchmark_profile

hamiltont added a commit to hamiltont/FrameworkBenchmarks that referenced this issue Jul 8, 2014

Enable framework-specific install directories and environment
This commit is my proof-of concept, only the 'go' test works right now.
You can look at go/ to see the changes required on a per-framework
basis - essentially I've modified go/setup.py to move the declaration
of the environment into go/bash_profile.sh

Each framework now gets a personal <framework>/installs directory, and
can declare any needed environment variables in
<framework>/bash_profile.sh, such as modifications to the PATH.

The FwBm code now provides an FWROOT environment variable to
*all* shell scripts (instead of ~/Frameworks being assumed).
Also, an IROOT environment variable is provided to any framework-specific
files (e.g. install.sh and bash_profile.sh) for the location of the install directory
for that framework. See go/bash_profile.sh to see me using both IROOT and
FWROOT.

By using IROOT, the strategy for installation is still controlled by python code and
the frameworks just reference IROOT and FWROOT in their scripts. These
variables are a nice step towards solving TechEmpower#448

The new function replace_environ in setup_util.py goes a long way towards
addressing TechEmpower#899 - as you can see I've removed all the changes to the ~/.bash_profile
from prerequisites.sh (and this commit serves as proof that everything still works) and
most of the changes from config/benchmark_profile

hamiltont added a commit to hamiltont/FrameworkBenchmarks that referenced this issue Jul 9, 2014

Enable framework-specific install directories and environment
This commit is my proof-of concept, only the 'go' test works right now.
You can look at go/ to see the changes required on a per-framework
basis - essentially I've modified go/setup.py to move the declaration
of the environment into go/bash_profile.sh

Each framework now gets a personal <framework>/installs directory, and
can declare any needed environment variables in
<framework>/bash_profile.sh, such as modifications to the PATH.

The FwBm code now provides an FWROOT environment variable to
*all* shell scripts (instead of ~/Frameworks being assumed).
Also, an IROOT environment variable is provided to any framework-specific
files (e.g. install.sh and bash_profile.sh) for the location of the install directory
for that framework. See go/bash_profile.sh to see me using both IROOT and
FWROOT.

By using IROOT, the strategy for installation is still controlled by python code and
the frameworks just reference IROOT and FWROOT in their scripts. These
variables are a nice step towards solving TechEmpower#448

The new function replace_environ in setup_util.py goes a long way towards
addressing TechEmpower#899 - as you can see I've removed all the changes to the ~/.bash_profile
from prerequisites.sh (and this commit serves as proof that everything still works) and
most of the changes from config/benchmark_profile

hamiltont added a commit to hamiltont/FrameworkBenchmarks that referenced this issue Jul 9, 2014

Enable framework-specific install directories and environment
This commit is my proof-of concept, only the 'go' test works right now.
You can look at go/ to see the changes required on a per-framework
basis - essentially I've modified go/setup.py to move the declaration
of the environment into go/bash_profile.sh

Each framework now gets a personal <framework>/installs directory, and
can declare any needed environment variables in
<framework>/bash_profile.sh, such as modifications to the PATH.

The FwBm code now provides an FWROOT environment variable to
*all* shell scripts (instead of ~/Frameworks being assumed).
Also, an IROOT environment variable is provided to any framework-specific
files (e.g. install.sh and bash_profile.sh) for the location of the install directory
for that framework. See go/bash_profile.sh to see me using both IROOT and
FWROOT.

By using IROOT, the strategy for installation is still controlled by python code and
the frameworks just reference IROOT and FWROOT in their scripts. These
variables are a nice step towards solving TechEmpower#448

The new function replace_environ in setup_util.py goes a long way towards
addressing TechEmpower#899 - as you can see I've removed all the changes to the ~/.bash_profile
from prerequisites.sh (and this commit serves as proof that everything still works) and
most of the changes from config/benchmark_profile

hamiltont added a commit to hamiltont/FrameworkBenchmarks that referenced this issue Jul 9, 2014

Enable framework-specific install directories and environment
This commit is my proof-of concept, only the 'go' test works right now.
You can look at go/ to see the changes required on a per-framework
basis - essentially I've modified go/setup.py to move the declaration
of the environment into go/bash_profile.sh

Each framework now gets a personal <framework>/installs directory, and
can declare any needed environment variables in
<framework>/bash_profile.sh, such as modifications to the PATH.

The FwBm code now provides an FWROOT environment variable to
*all* shell scripts (instead of ~/Frameworks being assumed).
Also, an IROOT environment variable is provided to any framework-specific
files (e.g. install.sh and bash_profile.sh) for the location of the install directory
for that framework. See go/bash_profile.sh to see me using both IROOT and
FWROOT.

By using IROOT, the strategy for installation is still controlled by python code and
the frameworks just reference IROOT and FWROOT in their scripts. These
variables are a nice step towards solving TechEmpower#448

The new function replace_environ in setup_util.py goes a long way towards
addressing TechEmpower#899 - as you can see I've removed all the changes to the ~/.bash_profile
from prerequisites.sh (and this commit serves as proof that everything still works) and
most of the changes from config/benchmark_profile

hamiltont added a commit to hamiltont/FrameworkBenchmarks that referenced this issue Jul 11, 2014

Enable framework-specific install directories and environment
This commit is my proof-of concept, only the 'go' test works right now.
You can look at go/ to see the changes required on a per-framework
basis - essentially I've modified go/setup.py to move the declaration
of the environment into go/bash_profile.sh

Each framework now gets a personal <framework>/installs directory, and
can declare any needed environment variables in
<framework>/bash_profile.sh, such as modifications to the PATH.

The FwBm code now provides an FWROOT environment variable to
*all* shell scripts (instead of ~/Frameworks being assumed).
Also, an IROOT environment variable is provided to any framework-specific
files (e.g. install.sh and bash_profile.sh) for the location of the install directory
for that framework. See go/bash_profile.sh to see me using both IROOT and
FWROOT.

By using IROOT, the strategy for installation is still controlled by python code and
the frameworks just reference IROOT and FWROOT in their scripts. These
variables are a nice step towards solving TechEmpower#448

The new function replace_environ in setup_util.py goes a long way towards
addressing TechEmpower#899 - as you can see I've removed all the changes to the ~/.bash_profile
from prerequisites.sh (and this commit serves as proof that everything still works) and
most of the changes from config/benchmark_profile

hamiltont added a commit to hamiltont/FrameworkBenchmarks that referenced this issue Jul 11, 2014

Enable framework-specific install directories and environment
This commit is my proof-of concept, only the 'go' test works right now.
You can look at go/ to see the changes required on a per-framework
basis - essentially I've modified go/setup.py to move the declaration
of the environment into go/bash_profile.sh

Each framework now gets a personal <framework>/installs directory, and
can declare any needed environment variables in
<framework>/bash_profile.sh, such as modifications to the PATH.

The FwBm code now provides an FWROOT environment variable to
*all* shell scripts (instead of ~/Frameworks being assumed).
Also, an IROOT environment variable is provided to any framework-specific
files (e.g. install.sh and bash_profile.sh) for the location of the install directory
for that framework. See go/bash_profile.sh to see me using both IROOT and
FWROOT.

By using IROOT, the strategy for installation is still controlled by python code and
the frameworks just reference IROOT and FWROOT in their scripts. These
variables are a nice step towards solving TechEmpower#448

The new function replace_environ in setup_util.py goes a long way towards
addressing TechEmpower#899 - as you can see I've removed all the changes to the ~/.bash_profile
from prerequisites.sh (and this commit serves as proof that everything still works) and
most of the changes from config/benchmark_profile
@hamiltont

This comment has been minimized.

Contributor

hamiltont commented Jul 14, 2014

@jyentechempower I think closing this is a bit premature - we should ideally wait until a directory restructure has been completed and tested. #915 make doing this a lot simpler, because you can start using variables instead of hard directory positions, but it doesn't actually restructure the folder locations at all

hamiltont added a commit to hamiltont/FrameworkBenchmarks that referenced this issue Jul 16, 2014

Enable framework-specific install directories and environment
This commit is my proof-of concept, only the 'go' test works right now.
You can look at go/ to see the changes required on a per-framework
basis - essentially I've modified go/setup.py to move the declaration
of the environment into go/bash_profile.sh

Each framework now gets a personal <framework>/installs directory, and
can declare any needed environment variables in
<framework>/bash_profile.sh, such as modifications to the PATH.

The FwBm code now provides an FWROOT environment variable to
*all* shell scripts (instead of ~/Frameworks being assumed).
Also, an IROOT environment variable is provided to any framework-specific
files (e.g. install.sh and bash_profile.sh) for the location of the install directory
for that framework. See go/bash_profile.sh to see me using both IROOT and
FWROOT.

By using IROOT, the strategy for installation is still controlled by python code and
the frameworks just reference IROOT and FWROOT in their scripts. These
variables are a nice step towards solving TechEmpower#448

The new function replace_environ in setup_util.py goes a long way towards
addressing TechEmpower#899 - as you can see I've removed all the changes to the ~/.bash_profile
from prerequisites.sh (and this commit serves as proof that everything still works) and
most of the changes from config/benchmark_profile

hamiltont added a commit to hamiltont/FrameworkBenchmarks that referenced this issue Jul 18, 2014

Enable framework-specific install directories and environment
This commit is my proof-of concept, only the 'go' test works right now.
You can look at go/ to see the changes required on a per-framework
basis - essentially I've modified go/setup.py to move the declaration
of the environment into go/bash_profile.sh

Each framework now gets a personal <framework>/installs directory, and
can declare any needed environment variables in
<framework>/bash_profile.sh, such as modifications to the PATH.

The FwBm code now provides an FWROOT environment variable to
*all* shell scripts (instead of ~/Frameworks being assumed).
Also, an IROOT environment variable is provided to any framework-specific
files (e.g. install.sh and bash_profile.sh) for the location of the install directory
for that framework. See go/bash_profile.sh to see me using both IROOT and
FWROOT.

By using IROOT, the strategy for installation is still controlled by python code and
the frameworks just reference IROOT and FWROOT in their scripts. These
variables are a nice step towards solving TechEmpower#448

The new function replace_environ in setup_util.py goes a long way towards
addressing TechEmpower#899 - as you can see I've removed all the changes to the ~/.bash_profile
from prerequisites.sh (and this commit serves as proof that everything still works) and
most of the changes from config/benchmark_profile
@hamiltont

This comment has been minimized.

Contributor

hamiltont commented Aug 10, 2014

Some thoughts on this:

  • Using language-specific directories would make it feasible to setup per-framework package management tools. For example, #966 discusses using Carton to ensure each framework gets to declare it's own Perl modules. Options exist for isolating environments in a variety of languages, but right now it would be tough to set this up without massive confusion. With the current setup, it's entirely possible that framework A runs fine on a clean VM, but does not run at all if framework B is installed first
  • I would love to see huge chunks of the main README moved into correct directories (e.g. into frameworks, frameworks/python, etc)

ps - @fernandoacorreia were you ever able to complete/merge your work on automating the deployment? That would be amazing...

@msmith-techempower

This comment has been minimized.

Member

msmith-techempower commented Aug 11, 2014

@hamiltont

With the current setup, it's entirely possible that framework A runs fine on a clean VM, but does not run at all if framework B is installed first

This is terrifying - can you give an example where this is true? I expect, apparently incorrectly, that each test is sandboxed with regard to everything except its dependencies (like nginx, java, etc).

@hamiltont

This comment has been minimized.

Contributor

hamiltont commented Aug 11, 2014

@msmith-techempower Given that you excepted dependencies, I'll give a contrived example for a potential problem that is not dependency (meaning some script we run under /toolset, not dependency in the broader sense) related. I don't have an example case where this happens currently, but that might just be because these issues would be very hard to spot - they would just look like a normal test failure, which we have a lot of at the moment.

contrived example : mojolicious currently requires the perl module Mango version 0.30. If a new test is added (mojo-orm or something) that requries mango 0.9, it's install.sh will install 0.9. The install.sh for mojolicious wouldn't roll back the mango version, it would just think everything is ok because a newer version is installed, and bam failure when you run mojolicious.
Disclaimer: I don't think this is actually possible for mojolicious or our other perl modules, because @jberger setup some nice perl module management stuff that I believe can declare "I specifically need mango 0.30"

bonus round : You may have noticed me complaining in general about installing stuff to the local system instead of installing stuff to a separate folder. There's a good reason, this causes potential for the exact same error as above, but for our dependency scripts. Pop up an ubuntu 12 box and run fw_depends mono nginx and watch the build fail with gcc: internal compiler error. Fun to do! But yea....bad for running our suite.

To completely invalidate my sentence, we need (1) all of our dependency scripts to install stuff into folders, and we need (2) to use language-specific package management solutions (I say environment in some places because a few languages can even change things like environment variables on a project-by-project basis). (1) is pretty simple, I think it will happen naturally as we're closing PRs. (2) is also pretty simple, but it depends heavily on closing this issue. Without a clean directory organization, (2) is the path to brimstone and dragons as you start changing little bits of toolset/ all over the place to detect what package management solution you're using

@hamiltont

This comment has been minimized.

Contributor

hamiltont commented Aug 15, 2014

organize the /frameworks directory by language first, and framework/platform second

This isn't supported yet, but it should be fairly simple to add in now. That PR was just getting too big to continue work on

@bhauer

This comment has been minimized.

Member

bhauer commented Aug 18, 2014

Awesome to have this one closed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment